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PREFACE 


This  RAND  Memorandum  is  one  in  a  continuing  series  on  the  tech¬ 
niques  of  digital  computer  simulation.  Each  Memorandum  covers  a 
selected  topic  or  subject  area  in  considerable  detail.  This  study 
discusses  computer  simulation  programming  languages.  It  describes 
their  characteristics,  considers  reasons  for  using  them,  compares  their 
advantages  and  disadvantages  relative  to  other  kinds  of  programming 
languages  and,  through  examples,  compares  four  of  the  most  popular 
simulation  languages  in  use  today. 

The  Memoranda  are  being  written  so  that  they  build  upon  one  another 
and  provide  an  integrated  coverage  of  all  aspects  of  simulation.  The 
only  Memorandum  in  the  series  that  needs  to  be  read  before  this  one  is 
P.  J.  Kiviat,  Digital  Computer  Simulation;  Modeling  Concepts.  The 
RAND  Corporation,  RM-5378-PR,  August  1967.  All  the  Memoranda  should 
be  of  particular  interest  to  personnel  of  the  AFLC  Advanced  Logistics 
System  Center,  Wright-Patterson  Air  Force  Base,  and  to  Air  Force  sys¬ 
tems  analysts  and  computer  programmers.  Persons  responsible  for 
selecting  simulation  programming  languages  for  particular  projects  or 
for  installations  of  computer  systems  should  find  this  Memorandum 
particularly  useful. 


-V- 


SUMMARY 


Simulation  progratnming  languages  are  designed  to  assist  analysts 
in  the  design,  programming,  and  analysis  of  simulation  models.  This 
Memorandum  discusses  basic  simulation  concepts,  presents  arguments  for 
the  use  of  simulation  languages,  discusses  the  four  languages  GPSS, 
SIMSCRIPT  II,  SIMOIA,  and  CSL,  summarizes  their  basic  features,  and 
comments  on  the  probable  future  course  of  events  in  simulation  language 
research  and  development. 

Simulation  languages  are  shown  to  assist  in  the  design  of  simula¬ 
tion  models  through  their  "world  view,"  to  expedite  computer  programming 
through  their  special  purpose,  high-level  statements,  and  to  encourage 
proper  model  analysis  through  their  data  collection,  analysis,  and 
reporting  features.  Ten  particularly  important  siiaulation  programming 
language  features  are  identified:  modeling  a  system's  static  state, 
modeling  system  dynamics,  statistical  sampling,  data  collection,  analysis 
and  display,  monitoring  and  debugging,  initialization  and  language 
usability.  Examples  of  each  of  the  four  simulation  languages,  GPSS, 
SIMSCRIPT  II,  SIMULA,  and  CSL,  .ire  used  to  illustrate  how  these  features 
are  implemented  in  different  languages. 

The  future  development  of  simulation  progranraing  languages  is 
shown  to  be  dependent  on  advances  in  the  fields  of  computer  languages, 
computer  graphics,  and  time  sharing.  Some  current  research  is  noted; 
outstanding  research  areas  are  identified. 
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I .  IWTRODUCTION 


The  Introductory  Memorandum  in  this  series  presented  a  rationale 
for  simulation,  discussed  why  simulation  experiments  are  performed, 
and  pointed  out  that,  while  computers  are  not  mandatory  for  simulation, 
most  simulations  today  require  computers  because  of  their  complexity 
and  sampling  requirements  [34]  .  Few  aspects  of  computer  technology 
are  vital  to  simulation,*  since  one  can  perform  simulations  without 
specialised  equipment.  Computers  make  it  easier  to  perform  a  simula¬ 
tion  study,  however,  and  the  frequent  savings  in  time  and  expense  allow 
more  time  to  be  spent  determining  the  reliability  of  aimulated  results 
and  designing  simulation  experiments. 

Specialized  computer  simulation  equipment  can  take  the  form  of 
either  hardware  (computers  and  peripheral  equipment)  or  software 
(compilers,  assemblers,  operating  systems).  This  Memorandum  Is  dedi¬ 
cated  to  software.  It  discusses  sin«ulation  languages,  describes  their 
characteristics,  considers  reasons  for  using  them,  and  compares  their 
advantages  and  disadvantages  relative  to  other  kinds  of  programming 
languages . 

SOME  DEFINITIONS 

A  reader  completely  unfamiliar  with  digital  computers  and  the 
basic  concepts  of  computer  programming  should  consult  an  introductory 
computer  programming  text  before  going  any  further.  References  [l] 
and  [22]  are  good  texts  for  the  purpose.  Readers  familiar  with  com¬ 
puters  and  at  least  aware  of  the  basic  concepts  of  progransning  should 
be  able  to  follow  this  Memorandum  without  additional  preparation. 

A  computer  programming  language  is  a  set  of  symbols  recognizable 
by  a  computer,  or  by  a  computer  program,  that  denote  operations  a  pro¬ 
grammer  wishes  a  computer  to  perform.  At  the  lowest  level,  a  basic 
machine  language  (BML)  program  is  a  string  of  symbols  that  corresponds 
directly  to  machine  functions,  such  as  adding  two  numbers,  storing  a 
number,  and  transferring  to  an  address.  At  a  higher  level,  an  assembly 

★ 

Excluding  analog  and  hybrid  simulation,  of  course. 
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language  (AL)  program  Is  a  string  of  mnemonic  symbols  that  correspond 
to  machine  language  functions  and  are  translatable  Into  a  basic  machine 
language  program  by  an  assembly  program  or  assembler .  Simple  assemblers 
do  little  but  substitute  bfisic  machine  language  codes  for  mnemonics 
and  assign  computer  addresses  to  variable  naraes  and  labels.  Sophisti¬ 
cated  assemblers  can  recognise  additional  symbols  (macros)  and  construct 
complicated  basic  machine  language  programs  from  them. 

A  cowintler  Is  a  program  that  accepts  statements  written  In  a 
usually  complex,  high-level  compiler  language  (CL)  and  translates  them 
Into  either  assembly  language  or  basic  machine  language  programs  -- 
which  may  In  turn,  at  least  in  the  case  of  CL  to  AL  translation,  be 
reduced  to  more  basic  programs.  Compilation  Is  much  more  complex  than 
assembly,  as  It  Involves  a  higher  level  of  understanding  of  program 
organisation,  much  richer  Input  languages,  and  semantic  as  well  as 
syntactic  analysis  and  processing. 

^  Interpreter  Is  a  program  that  accepts  Input  symbols  and,  rather 
than  translate  th?m  Into  computer  Instructions  for  subsequent  processing, 
directly  executes  the  operations  they  denote.  For  this  reason,  an 
Interpretive  language  (IL)  can  look  like  a  BML,  an  AL,  a  CL  or  anything 
else.  Interpretive  language  symbols  are  not  commands  to  construct  a 
program  to  do  something,  as  are  assembly  language  and  compiler  language 
commands,  but  commands  to  do  the  thing  Itself.  Consequently,  even 
though  programs  written  In  a  CL  and  an  IL  may  look  Identical,  they 
call  for  sharply  different  actions  by  the  programs  that  "underatand" 
them,  and  different  techniques  are  employed  In  writing  them. 

For  all  but  basic  machine  language  and  Interpretive  programs,  a 
distinction  has  to  be  drawn  between  the  program  submitted  to  the  com¬ 
puter,  the  source  language  program,  and  the  program  executed*  by  the 
computer,  the  object  program.  An  assembler  that  accepts  mnemonic  basic 
machine  codes  as  Its  Input  and  translates  them  Into  numerical  basic 
machine  codes  has  the  nnemonlcs  as  Its  source  language  and  the  numerical 
basic  codes  as  Its  object  language.  A  compiler  that  accepts  Engllsh- 
llke  language  statements  as  Its  Input  and  translates  them  Into  assembly 

* 

Excluding  sx>dlflcatlons  cade  during  loading. 


language  mnemonics,  which  are  in  turn  translated  into  numerical  basic 
machine  codes,  has  the  English-like  language  as  its  source  language 
and  the  numerical  basic  codes  as  its  object  language.  An  interpreter 
that  operates  by  reading,  interpreting,  and  operating  directly  on 
source  codes  has  no  object  code.  Every  time  an  interpretive  program 
is  executed,  a  translation  takes  place.  This  differs  from  what  is 
done  by  assemblers  and  compilers  where  translation  takes  place  only 
once,  from  source  to  object  language,  and  thus  enables  the  subsequent 
running  of  object  programs  without  translation. 

Basic  machine  language  and  assembly  language  programs  suffer  in 
that  they  are  specific  to  a  particular  computer.  Since  their  symbols 
correspond  to  particular  computer  operations,  programs  written  in  BML 
or  an  AL  are  meaningful  only  in  the  computer  they  are  designed  for. 

As  such,  they  can  be  regarded  as  machine  oriented  languages  (MOL) . 

Most  compilers  and  interpreters  csn  be  classified  as  problem 
orientea  languages  (POL).  As  such,  they  differ  from  BML  and  AL  that 
reflect  computer  'hardware  functions  and  have  no  problem  orientation. 

A  POL  written  for  a  particular  problem  area  contains  symbols  (language 
statements)  appropriate  for  formulating  solutions  to  typical  problems 
in  that  area.  A  POL  is  able  to  express  problem  solutions  in  computer 
independent  notation,  using  a  program  that  "understands"  the  POL  to 
translate  the  problem  solution  expressed  in  source  language  to  a  BML 
object  program  or  execute  it  interpretively. 

Figure  1  illustrates  a  BML,  an  AL,  and  two  POLs.  Each  example 
shows  the  statement  or  statements  (symbols)  that  must  be  written  to 
express  the  same  programming  operation,  the  addition  of  three  numbers. 


BML 

AL;  FAP 

POL:  FORTRAN 

POL:  COBOL 

+050000  . . . 

CLA  A 

X-A+B+C 

ADD  A,B  TO  C  GIVING  X 

+0A0000  . . . 

ADD  B 

+040000  ... 

+060100  . . . 

STO  X 

Fig.  1  --  A  programming  example 
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The  point  of  the  discuaalon  so  far  has  been  to  establish  the 
definitions  of  BML,  AL,  CL,  MOL,  POL,  assembler,  compiler,  and  inter¬ 
preter.  Without  these  definitions  it  is  impossible  to  understand  the 
historical  evolution  of  simulation  programming  languages  or  their  basic 
characteristics . 

A  simulation  Drograsaatng  language  (SPL)  is  a  POL  with  special 
features.  Simulation  being  a  problem-solving  activity  with  its  own 
needs,  programming  languages  have  been  vritten  to  make  special  features 
availablu  to  simulation  programmers  at  a  POL  level.  Historically,  this 
has  been  an  evolutionary  process.  SPLs  have  developed  gradually  from 
AL  programs  with  special  features,  through  extended  commercially  avail¬ 
able  POLs,  to  sophisticated,  special-purpose  SPLs.  Some  discussion  of 
these  special  features  is  necessary  to  place  the  development  process 
in  perspective  and  introduce  the  topics  that  follow.  Mot;,  complete 
histories  of  simulation  programming  languages  and  the  development  of 
simulation  concepts  can  be  found  in  Refs.  35,  36,  42,  43,  46,  60,  and  61. 

PRINCIPAL  FEATURES  OF  SIMULATKW  LANGUAGES 

Simulation,  as  defined  in  [34],  is  a  technique  used  for  reproducing 
the  dynamic  behavior  of  a  system  as  it  operates  in  time. 

To  represent  and  reproduce  system  behavior,  features  not  normally 
found  or  adequately  emphasised  In  most  programming  languages  are  needed. 
These  features: 

(1)  Provide  data  representations  that  permit  straightforward  and 
efficient  modeling, 

(2)  Permit  the  facile  portrayal  and  reproduction  of  dynasties 
within  a  modeled  system,  and 

(3)  Are  oriented  to  the  study  of  stochastic  systesis,  l.e.,  contain 
procedures  for  the  generation  and  analysis  of  random  variables  and  time 
series . 

The  first  of  these  features  calls  for  data  structures  note  elabo¬ 
rate  than  the  typical  uniubacripted-subscriptcd  variable  organisations 
found  In,  say,  F(H(TRAN  and  ALGOL.  Data  structures  must  be  richer  in 
t%K)  ways:  they  must  be  capable  of  complex  organisation,  as  In  tree 
structures,  lls^ta,  and  sets;  and  they  must  be  able  to  store  varieties 
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of  data,  such  as  numbers,  both  Integer  and  real,  double-precision  anl 
complex,  character  strings  of  both  fixed  and  variable  length,  and  data 
structure  references.  As  data  structures  exist  only  so  fnat  they  can 
be  manipulated,  statements  must  be  available  that  (1)  assist  in  ini- 

j 

tlallzlng  a  system  data  base  (as  we  may  call  the  collection  of  data 
that  describe  a  system);  (2)  permit  manipulations  on  the  data,  such 
as  adding  elements,  changing  data  values,  altering  data  structures 
and  monitoring  data  flows;  and  (3)  enable  communicAtion  between  the 
modeler  and  the  data.  PL/I,  the  newest  general-purpose  POL,  pays  great 
attention  to  data  structures,  although  not  as  much  as  some  people  would 
like  [29].  ALGOL  68,  the  revised  version  of  ALGOL  60,  also  leans  in 
this  direction  [18].  Activity  in  the  CODASYL  committee  charged  with 
improving  COBOL  shows  that  they  too  are  aware  of  the  importance  of  this 
topic  [55]. 

The  second  of  the  features  deals  with  modeling  formalisms,  both 
definitional  and  executable,  that  permit  the  simulation  of  dynamic, 
interactive  systems.  Statements  that  deal  with  time-dependent  descrip¬ 
tions  of  changes  in  system  state,  and  mechanisms  that  organize  the 
execution  of  vcrious  system-state-cliange  programs  so  that  the  dynamics 
of  a  system  are  represented  correctly,  are  an  integral  part  of  every  SPL. 

The  third  of  the  features  stems  from  the  fact  that  the  world  is 
constantly  changing  in  a  stochastic  manner.  Things  do  not  happen 
regularly  and  deterministically,  but  randomly  and  with  variation. 
Procedures  are  needed  that  generate  so-called  pseudorandom  variates 
from  different  statistical  distributions  and  from  empirical  sampling 
distributions,  so  that  real-world  variability  can  be  represented.  Pro¬ 
cedures  are  also  needed  for  processing  data  generated  by  simulation 
models  in  order  to  isakc  sense  out  of  the  masses  of  statistical  data 
they  produce.  [21] 

The  history  of  simulation-oriented  programming  languages  noted 
above  points  out  that  there  is  no  one  form  a  sioulation  language  must 
take,  nor  any  one  accepted  method  of  implementing  such  a  language.  An 
SPL  can  be  an  AL  with  special  instructions  In  the  form  of  oiacros  that 
perform  simulation-oriented  tasks,  a  CL  with  special  statements  that 
perform  essentially  the  same  tasks,  or  an  IL  with  statements  similar 
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to  tho*e  found  In  simulation-oriented  CLs  and  ALs  but  with  an  entirely 
dli.ferent  laplementatlon.  It  Is  sufficient  here  icerely  to  point  out 
the  principal  characteristics  of  all  SPLs,  providing  a  base  for  dlc- 
cusslng  why  SPLs  are  needed  and  for  understanding  some  pros  and  cons 
of  using  specialized  SPLs  and  general  POLs  for  sinoulation.  Sections 
TI  and  III  dlscuas  the  concepts  of  discrete-event  simulation  in  some 
detail  and  thoroughly  explore  the  features  noted  above. 

REA.SONS  POR  HAVING  SPLs 

The  two  most  frequently  cited  reasons  for  having  simulation  pro¬ 
gramming  languages  are  (1)  programming  convenience  and  (2)  centept 
articulation.  The  former  is  important  in  the  actual  writing  of  com¬ 
puter  programs,  the  latter  in  the  modeling  phase  and  in  the  overall 
approach  taken  Co  system  experimentation. 

It  is  difficult  to  say  which  of  the  two  is  more  important.  Cer¬ 
tainly,  many  simulation  projects  have  never  gotten  off  the  ground,  or 
at  least  we.-e  not  completed  on  time,  because  of  programming  difficulties. 
But  then,  other  projects  have  failed  because  their  models  were  poovly 
conceived  and  designed,  making  the  progtamoiing  difficult  and  the  required 
experimentation  impossible  or  nearly  so.  If  it  were  -ecessary  to  choose, 
concept  articulation  should  probably  be  ranked  first,  since  any  state¬ 
ments  or  features  provided  by  a  simulation  prograr aing  language  must 
exist  within  a  conceptual  framework. 

Succeeding  sections  examine  a  number  of  slmulatlo.i  programming 
concepts  and  how  they  are  implemented  In  different  SPLs.  Some  models 
are  also  described,  with  coascents  on  bow  various  conceptual  frameworks 
help  or  hinder  their  analysis  and  examination. 

It  is  fair  to  say  at  this  point,  before  going  through  this  demon¬ 
stration  and  without  documented  proof,  that  SPLs  have  contributed  to 
the  success  of  simulation  as  an  experimental  technique,  and  that  the 
two  featuies,  programming  convenience  and  concept  articulation,  are 
the  major  reasons  for  this  s.  ccess.  SIT.8  provide  languages  for 
describing  and  modeling  systems,  languages  composed  of  concepts  central 
to  Blraulation.  Before  these  concepts  were  articulated,  there  were  no 
words  with  which  to  describe  simulation  tasks,  and  without  words  there 
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wa8  no  coniDuinlcac ion  at  leaat  no  coraraunlcatlon  of  the  intensity  and 
scope  to  oe  found  today. 

A  third  substantial  reason  for  having  higher-level  SPLo  has  come 
about  through  their  use  as  communicatioi.  and  documentation  devices. 

When  wr'tten  in  English- like  languages,  simulations  can  be  explained  to 
project  managers  and  nonprograiumlrig-ortented  users  much  more  easily 
than  when  they  are  written  in  hieroglyphic  ALs.  Explanation  and 
debugging  go  easiei:  when  a  program  can  be  read  rather  than  deciphered. 

REASONS  FOR  USING  EXISTING  POLs 

Cogent  arguments,  both  technical  and  operational,  have  been 
advanced  for  avoiding  SPLs  and  sticking  with  tried-and-troe  algebraic 
compilers.  Technical  objections  dwell  mostly  on  object  program  effi¬ 
ciency,  debugging  facilities,  and  the  like.  Some  of  the  operational 
objections  are  the  noted  inadequacy  of  SPL  documentation,  the  lack  of 
transferability  of  SPL  programs  across  different  computers,  and  the 
difficulty  of  correcting  SPL  compiler  errors. 

Most  of  these  points  are  valid,  although  their  edge  of  truth  is 
often  exceedingly  Chin.  It  is  almost  necessarily  true  that  specialised 
sioulation  programming  languages  are  less  efficient  in  certain  aspects 
thsn  more  general  algebraic  compilers.  Bccauie  an  SPL  Lij  designed  for 
one  purpose,  it  is  less  efficient  for  another.  No  single  programning 
language  can  be  all  things  to  all  men,  at  least  not  today.  Painful 
experience  is  proving  this  to  be  true.  SPI^s  should  be  used  where  their 
advantages  outweigh  their  disadvantages,  but  not  criticised  for  their 
limitations  alone.  An  SPL  should  be  criticised  if  it  does  something 
poorly  it  was  designed  to  do,  l.e.,  »  simulation-oriented  task,  but 
not  if  it  is  inefficient  in  a  perinheral  nonslmulatlon-orlented  task. 

But  technical  criticisms  are  the  least  of  the  arguments  levied 
against  SPLs  by  people  seeking  to  justify  their  use  of  existing  alge¬ 
braic  POLu .  The  moat  serioua  and  justifiable  criticisms  are  those 
pertaining  to  the  use  of  individual  SPLs.  Unlike  the  comoKinly  used 
POli,  such  as  FORTRAN,  ALGOL,  and  COBOL,  which  are  produced  and  main¬ 
tained  by  computer  manufacturera ,  SPLs,  with  faw  exceptions,  have  been 
produced  by  Individual  organlsationa  for  their  own  purposee  and  relcaaed 


“8" 


to  the  public  more  as  a  convenience  and  Intellectual  gesture  than  a 
profitable  business  venture.  The  latter  are  too  often  poorly  documented, 
larded  with  undiscovered  errors,  and  set  up  to  operate  on  nonstandard 
systems,  or  at  least  on  systems  different  from  those  a  typical  user 
seems  to  have.  Wliile  attractive  intellectually,  they  have  often  been 
rejected  because  it  Is  simply  too  much  trouble  to  get  them  working.* 

In  a  programaing  community  accustot&ed  to  having  computer  manufacturers 
do  all  the  compiler  support  work,  most  companies  are  not  set  up  to  do 
these  things  themselves. 

The  answer  has  been,  "Stick  to  FORTRAN*  or  something  similar." 

It  is  easy  to  sympathize  with  this  sttitude,  but  It  is  unwise  to  agree 
in  all  cases.  For  a  stoall  organization  with  limited  programming 
resources,  doing  a  small  amount  of  simulation  work  under  such  a  strat¬ 
egy  is  probably  justifiable;  difficulties  can  be  eased  somewhat  by 
using  languages  such  ae  GASP  and  FORSIM  IV  that  are  actually  FORTRAN 
programming  packages  [19],  [37],  [53].  Large  organizations  that  have 
adequate  programming  resources  and  do  a  considerable  amount  of  simu¬ 
lation  work  are  probably  fooling  themselves  when  they  avoid  investing 
resources  in  an  SPL  and  stick  to  a  standard  POL.  One  reason  they  often 
decide  to  do  so  is  that  the  direct  costs  to  install  and  maintain  a  SPL 
are  visible,  while  the  incremental  costs  incurred  by  using  a  POL  are 
hidden  and  not  easily  calculated.  This  is  the  worst  kind  of  false 
economy.  Another  often-heard  excuse  is  that  programmers  and  analysts 
are  unwilling  to  learn  a  new  programming  language.  If  so,  they  should 
reform.  When  they  learn  to  use  an  SPL,  they  are  doing  far  more  than 
learning  a  new  prograoming  language;  they  are  learning  concepts  espe¬ 
cially  structured  for  sioiulaClon  modeling  and  programming  --  concepts 
that  do  not  even  exist  in  nonsimulation-oriented  POLs. 

Today,  the  designers  of  sioxilation  programming  languages  are  paying 
much  more  attention  to  their  users  than  they  have  in  the  past,  and 
computer  manufacturers  are  supporting  SPLs  much  more  readily.  While 
the  era  of  the  independently  produced  SPL  is  not  past,  it  has  probably 
seen  its  heyday.  Problems  of  system  compatibility  and  compiler  support 

★ 

With  the  exception  of  GPSS,  whicn  IBM  introduced  and  has  main¬ 
tained,  supported,  and  redesigned  three  times  <>lnce  1962. 
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wlll  diminish  in  Che  tuturc,  and  moat  operational, 
or  vaniah.  But  there  la  no  escaping  the  need  to  I 
our  only  choice  la  whether  to  volunteer  or  be  draf 


problems  will  fade 
earn  new  languages 
ted . 
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II.  SIMULATION  PBO?RAMMING  CONCEPTS 

Every  SFL  haa  a  amall  number  of  apecial  aloulatlon-orlented 
features  .  The  way  they  are  elaborated  and  Inpleinented  makea  particular 
SPLa  difficult  or  easy  to  use,  programmer-  or  analyst-oriented,  etc. 

They  support  the  concepts  embodied  in  the  definition  of  simulation 
used  in  this  aeries  of  Memoranda;  Che  use  of  a  numerical  model  to 
study  the  behavior  of  a  system  as  It  operates  over  time. 

Taking  the  key  words  In  this  definition  one  at  a  time  sets  forth 
basic  SFL  requirements; 

Use  ...  to  study  the  behavior:  an  SPL  must  provide  facilities 
for  performing  experlotencs ,  for  presenting  experimental 
results,  for  prescribing  experimental  conditions,  etc. 

Numerical  model  .  .  .  of  a  system:  an  SPL  must  provide  facilities 
for  describing  the  structure  of  a  great  variety  of  systems. 
Representations  are  needed  for  describing  the  objects  found 
In  systems,  their  quall(.les  and  properties,  and  relationships 
between  them. 

Operates  over  time:  an  SPL  must  provide  facilities  for  describing 
dynamic  relationships  within  systems  and  for  operating  upon 
the  system  representation  In  such  a  way  that  the  dynamic 
aspects  of  system  behavior  are  leproduced. 

This  section  concentrates  first  on  concepts  related  to  descriptions 
of  a  system's  static  structure  and  next  on  concepts  related  to  repre¬ 
senting  system  dynamics.  Section  1X1  discusses  features  needed  for 
the  efficient  and  practical  use  of  simulation  BK>dels. 

DESCRIBING  A  SYSTEM:  THE  STATIC  STRUCTURE 


The  static  structure  of  a  simulation  model  ta  a  time-independent 
fraoiework  within  which  system  states  are  defined.  System  states  are 
possible  configure. lou  ^  system  can  be  in;  in  numerical  models,  dif¬ 
ferent  system  states  are  represented  by  different  data  patterns. 
Dynamic  system  processes  act  and  interact  within  a  static  data  struc¬ 
ture,  changing  data  values  and  thereby  changing  system  states. 
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A  definition  of  a  pystem  paints  out  characteristics  that  are 
important  in  establishing  a  static  system  structure;  a  system  is  an 
Interacting  collection  of  objects  in  a  closed  environment,  the  bound¬ 
aries  of  which  are  clearly  stated.  Every  system; 

(a)  contains  Identifiable  classes  of  objects, 

(b)  which  can  vary  in  number, 

(c)  have  varying  numbers  of  identifying  characteristics, 

(d)  and  are  related  to  one  another  and  to  the  environment  in 
cnangeabie,  although  prescribed  ways. 

Simulation  prograosning  languages  must  be  able  to; 

(1)  define  the  classes  of  objects  within  a  system, 

(2)  adjust  the  number  of  these  objects  as  conditions  within  the 
system  vary, 

(3)  define  characteristics  or  properties  that  can  both  describe 
and  differentiate  objects  of  the  same  class,  and  declare 
(numerical)  codes  for  tham,  and 

(4)  relate  objects  to  one  another  and  to  their  common  environment. 
These  requirements  are  not  unique  to  SPLs;  they  are  also  found  in 
languages  and  programs  associated  with  information  retrieval  and  manage¬ 
ment  information  systems . 

While  It  might  be  interesting  to  examine  all  SPLs  and  contrast 
the  particular  ways  in  which  they  express  structural  concepts,  it 
would  hardly  be  practical.  For  one  thing,  they  are  too  numerous;  for 
another,  many  are  simply  dialects,  lineal  descendants  or  near  relatives 
of  a  small  number  of  seminal  languages.  In  the  interests  of  economy 
and  clarity,  only  the  basic  concepts  of  these  languages  are  discussed 
here.  Excellent  discussions  of  the  features  and  pros  and  cons  of  the 
most  widely  used  simulation  languages  can  be  found  in  Refs.  43,  60,  61, 
64,  and  66. 

Identification  of  Objects  and  Object  ChuracteriaticK 

All  SP)J  view  the  "real  world"  In  pretty  rrjch  the  same  way, 
and  reflect  this  view  in  the  data  structures  they  provide  for  re¬ 
presenting  systems .  3«sicelly,  systems  are  composed  of  cleases 
of  different  kinds  of  objects  that  arc  unique  and  can  be  identified  bN 
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dlstinguithlng  characterlst lea .  Objeers  are  referred  to  by  «uch  names 
ai  entity,  object,  tranaactlon,  resource,  facility,  storage,  variable, 
machine,  equipinent,  process,  and  element.  Object  characteristics  are 
referred  to  by  such  names  as  attribute,  parameter,  state,  and  descriptor. 
In  some  languages  all  objects  are  passive,  i.e.,  things  happen  to  them; 
in  some  languages  objects  are  active  as  well,  i.e.,  they  flow  through 
a  aysteffl  and  initiate  actions. 

Table  1  liats  several  popular  SPLs  and  shows  the  concept  names 
and  formalisms  associated  with  each. 


Table  1 

IDENTIFICATION  METHODS 


Language 

Concepts 

Example 

SIMSCRIPT  [33,  39,  45] 

Entity,  Attribute 

AGE(HAN)  read  AGE  OF  MAN 

SIMULA  [13,  14,  59] 

Process,  Attribute 

AGE  attribute  of  cur¬ 

rent  process  MAN 

CPSS  [23.  24,  26] 

Transaction,  Parameter 

PI  first  parameter  of 

current  transaction 

CSL  [7,  9,  11] 

Entity,  Property 

LOAD(SHIP) 

read  LOAD  OF  SHIP 

Relationships  between  Oblectt 

There  is  s  class  relstionshlp  between  objects  in  all  SPLs;  several 
object#  have  different  distinguishing  characteristics  and  are  in  that 
sense  unique,  but  have  s  coomon  bond  In  being  of  the  same  type.  For 
example,  in  a  system  containing  a  class  of  objects  of  the  type  SHIP, 
two  ships  may  have  Che  naaea  MARY  and  ELISABP"’'  The  objecta  arc 
different  yet  related. 

This  fem  of  relationship  is  rarely  strong  enough  for  all  purposes, 
and  nusc  be  supplemented.  It  is  almost  always  necessary  to  be  able  to 
relate  objects,  of  the  same  and  different  clesacs,  having  restricted 
physical  or  logical  relations  in  common.  For  example,  it  laight  bt 
necessary  to  identify  ell  SHlPa  of  a  particular  tonnage  or  ell  SHIPs 
berthed  in  a  particular  port. 
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To  this  end,  all  SPLs  define  relationship  mechanisms.  Names  such 
as  set,  queue,  list,  chain,  group,  file,  and  storage  are  used  to 
describe  them.  Each  language  has  operators  of  varying  power  that  place 
objects  in,  and  remove  them  from  relationship  structures,  determine 
whether  several  objects  are  In  particular  relationships  to  each  other, 
and  ao  on . 

Table  2  lists  the  relationship  concepts  of  the  languages  shown 
In  Table  1 . 


Table  2 


RELATIONSHIP  METHODS 


Language 

Concept 

Example 

SIMSCRIPT 

Set 

FILE  MAN  FIRST  IN  SET(I); 

Insert  KAN  Into  SET(I) 

SIMULA 

Set 

PRCD(X,MAN);  precede  element  X  with 

clement  MAN  in  the  set  to  which  X  belongs 

GPSS 

User  chain 
group 

LINK  I,  FIFO; 

put  current  transaction  first  In  Chain  I 

CSL 

Set 

MAN. 3  HEAD  SET(I);  put  the  third  man 
at  the  head  of  Set  I 

Generation  of  Objects 

Some  languages  deal  only  with  fixed  data  structures  that  are 
a)  located  either  durlr.g  compilation  or  at  the  start  of  execution. 

These  structures  represent  fixed  numbers  of  objects  of  different 
classes.  Other  languages  allow  both  fixed  and  varying  numbers  of 
objects.  There  Is  a  great  deal  of  variety  In  the  way  different  lan¬ 
guages  handle  the  generation  of  objects.  The  methods  are  related 
both  to  the  "world  view"  of  the  language  and  the  way  In  which  the 
language  la  expressed,  l.e.,  as  a  compiler,  an  Interpreter,  or  a  POL 
program  package.  lUny  of  the  dlff?,.ences  between  SIHSCRIFT  and  SIMULA 
can  be  treced  to  compiler  features  that  have  little  to  do  with  alaula- 
tlon  per  se.  The  block-structurc/procedure  orientation  of  SIMULA, 
which  la  rooted  in  ALGOL,  has  influenced  the  way  processes  are  generated 
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and  the  way  they  coonunlcate  with  one  another.  The  global-variable/ 
local-^'ariable/eubroutine  orientation  of  SIMSCRIPT,  which  ie  rooted 
in  FORTRAN,  has  similarly  Influenced  the  way  entities  are  generated 
and  the  way  they  coranunicate  with  one  another.  In  these  two  cases, 
the  differences  are  profound.  A  SIMULA  process  contains  both  a  data 
structure  and  an  activity  program;  a  SIMSCRIPT  entity  holds  only  a 
data  structure  and  is  linked  indirectly  to  an  event  subroutine.  Some 
of  the  consequences  of  this  division  can  be  seen  in  the  examples  of 
Sec.  IV. 

Table  j  deacriues  several  object  generation  methods. 

Table  3 


Language 


GENERATION  METHODS 


Concept 


SIMSCRIPT  Generate  a  new  entity 

!  whenever  one  is  needed 

SIMULA  Generate  a  new  process 

whenever  one  is  needed 


Example 


CREATE  A  MAN  CALLED  HENRY 


HENRY:-  new  MAN 


Generate  a  new  transaction  with 

some  specified  time  between  GENERATE  10,3 
successive  generetlons 

Does  not  exist 


Of  necessity,  these  illustrations  are  sketchy  and  not  indicative 
of  the  wealth  of  descriptive,  relational  and  operational  facilities 
offered  by  the  languages  quoted.  This  is  not  altogether  bad,  as  the 
purpose  here  is  to  Impart  a  flavor  for  the  ways  in  which  SFLs  describe 
static  syateoi  structures  and  not  to  teach  or  compare  features  of  par¬ 
ticular  languages.  The  reader  who  is  interested  in  the  specifics  of 
individual  languages  should  refer  to  their  respective  programming 
manuals . 

DESCRIBING  A  SYSTEM;  THE  DYNAMIC  STRUCTURE 


While  a  model's  static  structure  sets  the  stage  fox  simulation, 
it  is  its  dynamic  structure  that  oiakes  it  possible.  The  dynamics  of 
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system  behavior  in  all  SFLs  is  r-^preeented  procedurally,  that  is,  by 
computer  programs.  While  desirable,  no  nonpiocedural  SFLs  have  yet 
been  invented,  although  substantial  success  toward  this  end  has  been 
achieved  in  limited  areas  [25]. 

At  present,  two  SFLs  have  achieved  widespread  prominence  and  use 
in  the  United  States,  and  two  others  have  achieved  similar  prominence 
in  Europe  and  Great  Britain.  These  are  GPSS,  SIMECRIFT,  SIMl'LA,  and 
CSL,  respectively  Interestingly  enough,  each  presents  a  different 
view  of  system  dynamics.  To  understand  why  this  is  so,  a  historical 
rather  than  functional  discussion  seeais  appropriate. 

The  Concept  of  Slomlated  Time  |  i 

Soon  after  academics  and  practitioners  recognised  that  sirauratlonc  j 

of  industrial  and  military  processes  could  be  conducted  on  digital  com¬ 
puters,  they  started  to  separate  the  simulation-oriented  portions  of  ’ 

computer  programs  from  the  parte  describing  the  processes  being  simu¬ 
lated.  A  almulatlon  vocabulary  was  developed;  the  first  void  in  it 
was  probably  "clock."  Program  structures  began  to  reflect  the  concepts 
‘  embodied  in  the  vocabulary. 

Since  time  and  its  representation  are  the  essence  of  simulation, 
it  was  natural  for  It  to  be  the  first  item  of  concern.  If  one  could 
represent  the  passage  of  time  within  a  computer  program  and  associate 
the  execution  of  programs  with  specific  points  In  this  simulated  time, 

one  cou.’.d  claim  to  have  a  time -dependent  simulation  program.  ’  j 

The  first  simulation  clocks  imitated  the  behavior  of  real  ones.  j 

They  were  counters  that  "ticked"  in  unit  increments  representing  ' 

seconds,  minutes,  hours,  or  days,  providing  a  pulse  for  simulation  ■ 

programs.  liach  time  the  clock  ticked,  a  simulation  control  pionram 
looked  around  to  see  what  could  happen  at  that  Instant  in  simulated 
time.  Whet  could  happen  could  be  determined  in  two  ways:  by  pre- 

dete  truction  or  by  search.  Before  going  into  these  two  | 

techniques,  words  are  in  order  about  simulation  control  programs.  1 

r  :- 

! 

I 

t 

! 


j 


L 
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Tb.>  Structure  of  almuiatlon  Concrol  Progtame 

The  heart  o£  «very  tlmulatlon  program,  and  eve.ry  SPL,  Is  a  time 
control  program.  This  program  is  referred  to  in  various  publications 
as  a  clockworks,  a  simulation  executive,  a  timing  mechanism,  a  sequencing 
set,  and  ttie  like.  Its  functions  are  always  the  sane:  to  advaitce 
sltpulation  time  and  to  select  a  subprogram  for  execution  that  performs 
a  specified  simulation  activity. 

Thus,  every  simulation  program  has  a  hierarchical  structure.  At 
the  top  sits  the  time  control  program,  at  an  intermediate  level  sit 
simulation-oriented  routines,  at  the  bottom  sit  loutlnes  Miat  do  basic 
housekeeping  functions  such  as  Input,  output,  ai'.d  the  computation  of 
mathematical  functions.  Every  SPL  provides  a  time  control  program; 
when  using  an  SPL,  a  simulation  programmer  does  not  have  to  write  one 
himself  --  or  even  worse,  invent  one, 

Depending  on  how  the  time  control  program  works,  a  simulation 
progranuner  may  or  may  not  have  to  use  special  stacr.nients  to  interact 
with  the  timing  mechanism.  Moat  simulation  languages  contain  one  or 
mure  statements  that  permit  a  prograrsner  to  organize  system  activities 
In  a  time-dependent  manner.  Further  on,  this  section  deocrlbes  several 
different  simulation  control  program  schemes  and  the  ways  in  which  a 
programmer  Interacts  with  them. 

First,  it  must  be  unde’^stuod  that  every  simulation  program  Is 
composed  of  blocks  of  statements  that  deal  with  specific  system  activ- 
Itlcc.  These  blocks  ovay  be  complete  routines*  or  parts  of  routines. 

They  have  been  called  events,  activities,  blocks,  processes,  and  seg¬ 
ments.  The  distinctions  between  them  will  be  clarified  presently;  at 
the  moBent  It  Is  only  necessary  to  understand  that  a  simulation  program 
Is  composed  of  Identifiable  modules  that  deal  with  different  simulate  jn 
situations  • 

A  slsiuiatlon  control  progren  can  select  a  portion  of  code  to 
execute  in  either  of  two  ways;  by  predetermined  instruction  or  by 


The  words  routine,  subroutine,  program,  subprogram,  and  procedure 
are  uced  here  interchangeably. 
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search.  Regardless  of  how  the  result  Is  determined,  the  effect  Is  the 
same  —  the  execution  of  an  appropriate  block  of  code.  Figure  2  blocks 
out  the  basic  structure  of  every  simulation  program. 


Fig.  2  —  Basic  simulation  structure 


SlBulatlon  starts  at  I,  where  a  model  Is  Initialised  with  sufficient 
data  to  describe  Its  Initial  system  state  and  the  processes  that  are 
In  motion  within  it .  Based  on  Information  computed  In  the  "next  event" 
block,  5)  switches  to  the  code  block  that  corresponds  to  the  proper 
simulation  activity. 

The  "search"  method  of  next-event  selection  relies  upon  the  fact 
that  when  a  system  operates  it  moves  from  state  to  state  in  a  pre¬ 
determined  manner.  The  times  at  which  state  changes  occur  may  be 
random,  and  represent  the  effects  of  statistically  varying  situations, 
but  basic  cause-and-effect  relations  still  hold.  Given  that  a  system 
is  In  state  "A",  it  will  always  move  Into  state  "B"  If  certain  condi¬ 
tions  hold;  code  block  AB,  say,  must  always  be  executed  to  effect  the 
change.  A  "search"  method  relies  upon  descriptions  of  activity- 
producing  system  states  and  a  scanner  that  examines  system  state  data 
to  determine  whether  a  state  change  can  take  place  at  any  particular 
clock  pulse. 
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When  a  state  change  can  be  made,  the  code  block  representing  It 
alters  data  values  to  reflect  the  change.  Since  oiany  system  changes 
take  place  over  a  period  of  time,  some  of  the  data  changes  are  to 
"entity  clocks."  These  clocks  are  set  to  the  simulated  time  at  which 
a  state  change  Is  considered  completed.  ..When  the  control  program  finds 
that  an  "entity  clock"  has  the  same  time  as  the  master  simulation  clock, 
It  performs  the  activity  associated  with  that  clock,  e.g.,  relegating 
a  working  machine  to  Idleness  or  causing  an  emptying  tank  to  run  dry. 
State  changes  that  happen  Instantaneously,  either  when  a  code  block 
Is  executed  or  as  the  result  of  some  entity  clocks  equaling  the  sim¬ 
ulation  clock,  cause  new  code  blocks  to  be  executed,  new  entity  clocks 
to  be  set,  .  .  .,  cause  the  system  activities  to  be  reexamined. 

The  efficiency  of  this  rather  basic  scheme  was  first  Improved  by 
eliminating  the  uniform  clock  pulse.  Since,  In  many  simulations, 
events  do  not  occur  on  every  clock  pulse  but  randomly  In  time,  a  great 
deal  of  computer  time  can  be  lost  In  scanning  for  things  to  do  each 
time  the  clock  is  advanced  one  Incresient .  It  Is  more  efficient  to 
specify  the  tlom  at  %«hlch  the  next  event  is  to  occur  and  to  advance 
the  clock  to  this  time.  As  nothing  can  happen  before  this  time,  it 
la  unnecessary  to  search  for  altered  system  states.  By  definition  of 
the  next  event,  no  entity  clock  can  have  an  earlier  time.  At  best. 

It  can  only  be  equal  to  the  next  event  time. 

The  term  "next-event  simulation"  was  given  to  simulation  prograou 
that  stepped  from  event  time  to  event  time,  passing  over  Increments 
of  time  In  which  no  state  changes  occurred.  All  modem  SPLs  use  the 
next-event  technique .  The  term  critical  event  Is  often  used  in  the 
same  spirit. 

Two  SPLs  that  do  employ  search  are  GSP  [62]  and  CSL.  In  both,  the 
activity  is  the  basic  dynamic  unit.  An  activity  Is  a  program  composed 
of  a  test  section  and  an  action  section.  Whenever  simulation  tloK  la 
advanced,  all  activity  programs  are  scanned  for  possible  performance. 

If  all  test  conditions  in  an  activity  arc  met,  state- changing  and  time- 
setting  Instructions  In  the  action  section  are  executed;  If  at  least 
one  test  condition  is  not  met,  the  ectlon  instructions  arc  passed  over. 
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A  cyclic  scanning  of  activity  programs  insures  Chat  all  possibilities 
are  examined  and  all  interactions  are  accounted  for. 

In  addition  to  the  activities  scan.  GSP  incorporates  an  event 
scheduling  mechanism  that  enables  an  activity  to  specify  chat  some 
system  event  is  to  take  place  at  a  determined  time  in  the  future. 

Events  that  are  not  affected  by  other  events,  i.e.,  are  not  heavily 
interactive,  can  be  treated  more  efficiently  this  way,  as  repeated 
scanning  is  not  required  to  determine  when  they  can  be  done . 

When  an  activity  scan  is  not  employed,  as  is  the  case  in  CPSS, 

SIMSCRIPT,  and  SIMULA,  all  system  events  must  be  predetermined  and 
scheduled.  The  activity-scan  and  event-scheduling  approaches  are  dif 
ferent  solutions  to  the  same  problem;  an  activity  scan  is  efficient 
for  highly  interactive  processes  Involving  a  fixed  number  of  entitles,  | 

e.g.,  multiresource  assignment  problems  In  shops  producing  homogeneous  | 

products;  event  scheduling  is  efficient  for  less  interactive  processes  I 

involving  large  numbers  of  entities,  e.g.,  simulations  of  Job  shops  ) 

producing  special  order  products.  Efflcl'incy  must  be  treated  as  a 
nult id Imens Iona  1  quality,  of  course.  We  must  speak  of  modeling  effi¬ 
ciency  and  programming  efficiency,  as  well  as  computer  running-time 
efficiency . 

The  differences  between  activity  scanning  and  event  scheduling 
orientations  can  be  pointed  out  best  by  procedural  desciiptlons . 

Event  Selection  Procedures 

Take  a  simple  shop  situation  in  which  a  man  and  a  machine  must 
work  together  to  produce  a  part.  Each  has  an  Independent  behavior, 
in  that  the  man  starts  his  day  and  ends  It,  takes  coffee  breaks,  and 
goee  to  lunch  without  regard  for  how  the  machine  is  performing,  and 
the  machine  suffers  breakdow.is  and  power  failures  without  regard  for 
what  the  man  may  be  doing. 

The  Activity  Scanning  Approach.  An  activity  approach  to  simulating 
the  processing  of  a  part  in  this  man-mschlne  shop  specifies  the  condi- 
tlona  for  a  job  to  start  processing,  and  the  actions  that  take  place 
when  such  conditions  are  tner : 
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Test  section; 

if  part  la  available  AND 

if  machine  is  idle  AND 

if  man  is  idle  THEN  do  Action  section 

OTHERVnSE  return  to  timing  mechanism 

Action  section: 

put  man  in  committed  state 

put  machine  in  committed  state 

determine  time  man  will  be  engaged 

determine  time  machine  will  be  engaged 

set  man-clock  to  time  man  will  become 
available 

set  machine-clock  to  time  machine  will 
become  available 

return  to  timing  mechanism 

Emphasla  la  on  che  activity  of  producing  the  part,  not  on  the 
Individual  roles  of  the  ii>an  and  the  machine.  Periodic  scanning  of 
the  activity  finds  inatancea  when  all  three  conditions  hold. 

The  Event  Scheduline  Approach.  An  event  scheduling  approach  to 
the  same  problem  requires  that  three  progracne  be  written,  one  for  the 
man,  one  for  the  machine,  and  one  for  the  part.  The  programs  contain 
both  test  and  action  statements,  and  are  "menus"  for  situations  that 
can  take  place  whenever  a  state  change  event  occurs.  For  example, 
one  event  in  the  simulation  of  the  above  man-machine  shop  would  be 
the  return  of  a  man  to  the  Idle  state  from  whatever  activity  h«  might 
have  been  engaged  in.  The  routine  that  repreaents  the  "man  becomes 
Idle"  event  might  look  like; 


Test  section: 


Action 


Action 


section 


section 


if  part  is  available  AND 

if  machine  Is  idle  THEN  do  Action  section 
OTHERWISE  do  Action  section^ 

put  nan  in  committed  state 
put  machine  in  committed  state 
determine  time  man  will  be  engaged 
determine  time  machine  will  be  engaged 
schedule  return  of  man  to  availability 
schedule  return  of  machine  to  availability 
return  to  timing  mechanism 

put  man  in  idle  state 
return  to  timing  mechanism 


1 


While  these  two  program  protocol®  may  look  similar,  they  are 
<5ulte  different.  The  event  program  is  executed  only  when  a  state  change 
occurs;  the  activity  program,  on  the  other  hand,  is  examined  at  each 
timing  cycle  to  aec  if  a  state  change  car  take  place.  Furthermore, 
the  activity  contains  logic  for  the  availability  of  part,  man,  and 
machine,  while  three  event  programs  must  be  written  for  the  return  of 
a  man,  machine,  and  part  --  testing,  respectively,  that  a  machine  and 
part,  loan  and  part,  and  man  and  machine  are  available. 

Neither  approach  is  clearly  superior  to  the  other;  each  has  its 
advantages  in  some  situations.  Differences  aoiong  SPLt  that  utilise  one 
approach  or  anotiier  usually  stem  from  their  authors'  attempts  to  design 
a  language  suited  to  the  particular  class  of  problems  they  study  and 
hence  gain  modeling,  programing,  and  execution  efficiency. 

The  Process  Interaction  Approach.  One  of  the  difficulties  of 
the  event  approach  is  its  division  of  the  logic  of  an  operating  system 
into  small  parts.  The  activity  approach  saeias  to  suffer  less  from  this 
criticism.  A  third  approach,  called  the  process,  attempts  to  combine 
the  efficiencies  of  event  scheduling  with  the  concise  notation  of 
activity  scanning. 
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A  proceas  can  be  defined  aa  a  aet  of  events  that  are  associated 
with  a  system  behavior  description.  The  events  are  Interrelated  by 
special  scheduling  statements,  such  as  DELAY,  WAIT,  and  WAIT  UNTIL, 
that  Interrupt  the  execution  of  a  subprogram  until  a  specified  period 
of  time  has  passed  or  a  stated  aet  of  conditions  hold.  DELAY  and  WAIT 
are  tlme-orlented  and  are  effected  through  event  scheduling  techniques. 
WAIT  UNTIL,  being  condl tlon-orlented .  requires  an  actlvlty-acan  approach. 
A  process  description  thereby  combines  the  run-time  efficiency  of  event 
scheduling  with  the  modeling  efficiency  of  activity  scanning.  SIMULA 
Is  a  process-oriented  language  chat  has  had  several  years  of  successful 
experience  and  has  undergone  one  revI::ion  [16].  GPSS  is  a  process- 
oriented  language  with  a  longer  history  and  even  more  widespread  accep¬ 
tance.  Although  It  Is  f low-chart-orlented  rather  than  statement- 
oriented,  the  basic  j roceas  concepts  expressed  here  apply  Co  it. 

A  key  feature  of  process-orientation  Is  that  a  single  program  Is 
made  Co  act  as  chough  It  Is  several  programs,  Independently  controlled 
either  by  activity- type  scans  or  event  scheduling.  Each  process  has 
several  points  at  which  It  Interacts  with  other  processes.  Each  process 
can  have  several  active  phases;  eech  active  phase  of  a  process  Is  an 
event.  This  Is  different  from  pure  event  or  activity  approaches  that 
allow  an  Interaction  only  when  all  the  actions  associated  with  an  event 
or  activity  have  been  completed,  e.g.,  when  they  return  to  the  timing 
irechanlsm . 

The  programming  feature  that  stakes  this  scheoie  possible  Is  the 
reactivation  point,  which  Is  essentially  a  pointer  that  Cells  a  process 
routine  where  to  start  execution  after  sosie  time-delay  command  has  been 
executed.  Figure  3  Illustrates  the  concepts  of  Interaction  point  and 
reactivation  point  for  prototype  event,  activity  and  process  routines. 

In  Fig.  3a,  there  la  one  reactivation  point  and  one  Interaction 
point.  An  event  routine  always  starts  at  the  same  executable  statentent, 
and,  while  It  may  have  several  physical  RETURN  statements,  only  one  can 
be  executed  in  any  activation.  When  it  is  executed,  it  returns  control 
to  Che  master  control  program,  which  selects  Che  next  event  (previously 
scneduled)  to  occur.  All  actions  taken  within  the  event  routine  take 
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reactivatlon  EVENT  ARRIVAL  routine  declaration 

point - ► 

SCHEDULE  AN  ARRIVAL  AT  100.0  creation  of  a  future 

Interaction  point 

actions  to  change  system  state 

return  Interaction  with  other 

events  takes  place 
when  routine  returns 
to  control  program 


(a)  Prototype  event  routine 


reactivation 
point  - 


reactivation 
point  - 

reactivation 
point  - 

reactivation 
point - 

reactivation 
pol nt - 


ACTIVITY  BERTHING 


routine  declaration 


testa  to  determine  If  act  activity  tests 

can  occur 

actions  taken  during  berthing  executed  if  tests 

indicate  activity 
can  occur 

Interaction  with  other 
activities  when 
routine  returns  to 
control  program 


RETURN 

END 


(b)  Prototype  activity 

PROCESS  SHOPPING 
actions  to  start  shopping 
WAIT  15  MINUTES 


routine 

routine  declaration 

Interaction  point 


actions  to  shop 


WAIT  UNTIL  SERVER  IS  FREE  Interaction  point 

actions  to  check  out 

DELAY  10  MINUTES  interaction  point 

actions  to  return  home 

SCHEDULE  SHOPPING  IN  15  MINUTES  creation  of  future 

interaction  point 


actions  to  renew  shopping  process 


END 


interaction  point 


(c)  Prototype  process  routine 


Fig.  3  --  Concepts  of  interaction  point  and  reactivation  point 


place  at  the  saiae  simulated  time,  Independently  of  other  events.  The 
event  is  not  totally  divorced  from  other  events,  as  all  events  share 
the  same  system  data. 

In  Fig.  3b,  there  is  again  only  one  reactivation  point  and  one 
logical  interaction  point.  If  an  activities  test  section  permits  them 
to  take  place,  all  actions  oc<'ur  at  the  same  aimulated  time. 

Figure  3c  presents  a  sharply  different  picture,  with  many  reacti¬ 
vation  and  interaction  points. 

Figures  3a,  b,  and  c  show  that  reactivation  and  interaction  points 
always  rome  in  pairs.  A  minute's  reflection  will  show  that  this  has 
to  be  so.  At  each  interaction  point  a  reactivation  point  is  defined, 
which  is  the  place  execution  will  start  when  the  indicated  time  delay 
elapses  or  the  condition  being  sought  occurs.  Within  a  process  routine, 
all  actions  do  not  necessarily  take  place  at  the  same  simulated  time, 
but  through  a  series  of  active  and  passive  phases. 

The  reader  should  be  able  to  see  the  differences  among  the  event, 
activity,  and  process  prototypes  and  get  a  qualitative  feel  for  how 
the  three  differ. 

Each  modeling  scheme  has  distinct  virtues.  Each  can  be  shown 
to  be  advantageous  in  some  situations  and  disadvantageous  in  others. 
There  are  no  rules  for  selecting  one  scheme  over  another  in  given 
situations,  nor  is  it  likely  that  any  such  rules  will  ever  be  stated. 
The  universe  of  possible  simulation  models  is  so  large  and  so  diverse 
that  there  would  undoubtedly  have  to  be  store  exceptions  than  firm  rules. 
Several  points,  however,  are  clear: 

A  language  employing  event  scheduling  gives  a  modeler  precise 
control  over  the  execution  of  programs. 

A  language  employing  activity  scanning  simplifies  modeling  multi- 
resource  systems  by  allowing  conditional  statements  of  resource  avail¬ 
ability  to  be  specified  in  one  place. 

A  procese-criented  language  reduces  the  number  of  "overhead" 
statements  a  programmer  has  to  write,  since  he  can  combine  tnany  event 
subprograms  in  one  process  routine.  In  addition,  the  overall  flow  of 
a  system  is  clear,  as  all  logic  is  contained  in  one  routine  rather 
than  several. 
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On  the  other  hand,  there  Is  nothing  one  scheme  can  do  that  another 
cannot.  Queationa  of  feasibility  must  be  separated  from  questions  of 
efficiency.  Also,  as  more  experience  is  gained  with  languages  employing 
these  schemes,  more  efficient  algorithms  will  be  developed  and  efficiency, 
per  ae,  will  become  less  of  a  problem.  Eventually,  modeling  esthetics 
will  become  an  overriding  consideration. 

Table  A  categorizes  many  of  the  SPLs  used  today  according  to  the 
dynamic  modeling  scheme  they  employ. 


Table  A 

SPL  DYNAMIC  MODELING  SCHEMES 


Event-oriented 

Languages 

Activity-oriented 

Languages^ 

Process -oriented 
Languages 

GASP 

AS  [51] 

GPSS 

SEAL  [56] 

CSL 

NSS  [50] 

SIMCOM  [58] 

ESP  [65] 

OPS  [27] 

SIMPAC  [2] 

FORSIM-IV 

SIMPLE  [17] 

SIMSCRIPT 

GSP 

1 

SIMULA 

SIKTRAN  [5] 

MILITRAN  [48] 

SLANG  [32] 

SILLY  [57] 

SOL  [Al] 

SIMON  [31] 

SPL  [52] 

^Sorne  of  these  languages  are  not  "pure,"  e.g., 
GSP  and  MILITRAN  have  both  activity-scan  and 
event-selection  phases.  The  principal  orienta¬ 
tion  Is  as  Indicated,  however. 


a 
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III.  SIMULATION  PROGRAMMING  LAliGUAGE  FEATURES 


SPECIFYING  SYSTEM  STRUCTURE 


Every  SPL 
both  Ita  static 
features  needed 


Dsust  have  some  way  of  describing  system  structure  In 
and  dynamic  aspects.  Section  II  discussed  the  principal 
for  this;  Table  3  sunmarlzes  them. 


Table  5 

SYSTEM  MODELING  FEATURES 
Stateosints  to: 

Define  classes  of  objects  within  a  system 
Adjust  the  number  of  objects  within  a  class 
as  system  conditions  change 
Define  properties  of  system  objects 
Describe  relationships  among  system  objects 
Define  activities,  events,  or  processes 
Organise  events  or  processes 

Programs  to : 

Select  activity,  event,  or  process  subprograms 
for  execution 
Advance  simulation  time 


REPRESENTING  STATISTICAL  PHENOMENA 


To  model  the  real  world,  one  must  have  a  way  of  modeling  random 
factors  and  effects.  It  is  necessary  to  model  undertainty  and  vari¬ 
ability  with  equal  ease. 

Uncertainty  enters  into  models  in  statemenLs  such  as: 

In  situation  X,  13  percent  of  the  time  Y  will  occur 
and  83  percent  of  the  time  Z  will  occur.  Given  that 
a  system  is  in  state  X,  some  probabilistic  mechanism 
la  required  to  select  either  state  Y  or  state  Z  as  the 
next  state . 

Variability  enters  into  models  In  statements  such  as: 

The  time  to  travel  from  A  to  B  has  an  exponential 
distribution  with  s  mean  of  3  hours,  or  the  number 
of  customers  expected  to  arrive  per  hour  has  a 
Poisson  distribution  with  a  mean  of  6.  A  proba¬ 
bilistic  mechanism  must  be  available  for  generating 
samples  from  statistical  distributions. 
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In  reproducing  variability  or  uncertainty,  a  simulation  model 
must  have  a  way  of  gcneratlnR  random  variables .  A  basic  feature  of 
every  SPL  is  a  randem-number  generator.  Additional  features  are  pro¬ 
grams  that  tranjforo  random  numbers  Into  variates  from  various  statis¬ 
tical  distributions  and  perform  related  sampling  tasks. 

A  process  is  random  if  predictions  about  its  fu.'ure  behavior 
cannot  be  improved  from  a  knowledge  of  its  past  behavior.  A  sequence 
of  numbers  is  a  random  sequence  if  there  is  no  correlation  between 
the  numbers,  i.e.,  if  there  is  no  way  to  predict  one  number  from  another. 
Random  numbers  are  needed  to  introduce  uncertainty  and  variability  into 
models,  but  because  of  the  kinds  of  experiments  that  are  performed  with 
simulation  models,  truly  random  sequences  of  numbers  are  not  adequate. 

One  must  have  reproducible  sequences  of  numbers  that  are,  for  all 
intents  and  purposes,  random  so  far  as  their  statistical  properties 
are  concerned. 

Pseudorandom  numbers,  as  reproducible  screams  of  randomlike 
numbers  are  called,  are  generated  by  mathematical  formulae  In  such  a 
way  that  they  appear  to  be  random.  Since  they  are  not  random,  but 
come  from  deterministic  series,  they  can  only  approximate  the  indepen¬ 
dence  of  truly  random  number  sequences.  Every  simulation  study  calls 
for  verification  of  random-number  generators  to  insure  that  the  sta¬ 
tistical  properties  are  adequate  for  the  experiment  being  performed 
[20j.  Every  SPL  must  have  a  procedure  for  generating  statistically 
acceptable  sequences  of  pseudorandom  numbers. 

Pseudorandom  number  sequences  always  consist  of  numbers  that  are 
statistically  Independent  and  uniform'  LStributed  between  0  and  1. 
Generation  of  a  pseudorandom  number  ea  a  real  number  somewhere 

In  this  range. 

Pseudorandom  numbers  can  be  used  directly  for  statistical  sampling 
tasks.  They  can  represent  probabilities  in  a  decision  sense  or  in  a 
sampling  sense.  The  model  statement; 

Make  decision  Dj^  60  percent  of  the  time. 

Make  decision  40  percent  of  the  time. 


can  be  impleaiented  in  an  SPL  by  generating  a  pseudorandom  number  and 
testing  whether  it  lies  between  0.0  and  0.60.  If  it  is,  declslor 
is  taken;  if  it  is  not,  decision  is  taka  i .  For  a  sufficiently  large 

number  of  samples,  will  be  selected  60  percent  of  the  time,  but  the 
individual  selections  of  or  be  independent  of  previous 

selections . 

The  model  statement: 

Produce  product  P^  20  percent  of  the  time. 

Produce  product  P2  10  percent  of  the  time, 

Produce  product  P^  15  percent  of  the  time. 

Produce  product  P^  20  percent  of  the  tfme. 

Produce  product  P^  35  percent  of  the  time, 

can  be  Implemented  in  a  similai  way  by  sampling  from  a  cumulative 
probability  distribution.  A  random  product  code  can  be  drawn  from 
Che  above  product  mix  by  putting  the  product  frequency  data  into  a 
Cable  surn  as 


Product  type 

Cumulative  probability 

1 

0,20 

2 

0.30 

3 

0.45 

0.65 

5 

1 .00 

In  this  Cable,  the  olfference  between  the  successive  cumulative  prob¬ 
ability  values  is  the  probability  of  producing  a  particular  product; 
e.g.,  product  3  Is  produced  0.45  -  0.30  ■  O.lj  or  15  percent  of  the 
time.  When  a  pseudorandom  number  is  generated  and  matched  egainet  Che 
cable,  a  random  product  aelection  la  made.  Fcr  example,  generating 
the  number  0.42  aelecte  product  3.  Since  numbets  between  0.30  and 
0.45  will  be  generated  15  percent  of  the  time,  15  percent  of  the  product 
numbers  generated  will  be  iype  3. 

While  this  type  of  sampUns  is  uaeful  for  empirical  frequency 
dlsCributlone,  it  is  less  useful  for  sampling  from  tCeCistlcal 
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dtstributtone  such  as  the  exponential  and  normal.  To  use  a  cable  look¬ 
up  procedure  suc.i  as  the  one  describee  above,  and  sample  accurately 
In  the  tails  of  a  statistical  distributlort,  large  tables  must  be  stored. 
Generally,  a  simulation  cannot  afford  the  tables,  needing  the  storage 
for  model  data  and  program.  Algorithms  rather  than  table  look-up. 
procedures  are  used. 

Sampling  algorithms  are  of  many  kinds.  Some  distributions  are 
easily  represented  by  exact  mathemat leal  formulae,  seme  must  be  approx¬ 
imated.  All  sampling  methods  operate  in  the  same  way  Insofar  as  they 
transform  a  pseudorandom  number  to  a  number  from  a  particular  statietica 
distribution.  References  10,  49,  and  63  discuss  such  procedures  in 
detail.  As  simulation  is  almost  always  performed  using  sampling,  pro¬ 
cedures  tl'.at  can  generate  samples  from  standard  statistical  distribu¬ 
tions  are  mandatory  in  an  SPL. 

In  conducting  sampling  experiments,  which  is  what  simulations 
really  are,  one  is  interested  in  control  and  precision  as  well  ae 
accura.y  of  representation.  The  topics  dealt  with  so  far  have  ail  been 
concerned  with  representation. 

Control  it  necessary  when  one  is  using  simulation  to  test  and 
compare  alternative  lulss,  procedures,  or  qualities  of  equipment.  When 
several  simulatior.  runs  are  made  that  differ  only  in  one  carefully 
altered  aspect,  it  is  important  that  all  other  aspects  remain  constant. 
O^e  must  be  able  to  introduce  changes  only  where  th.ey  are  desired. 

This  is  one  of  the  reasons  for  requiring  reproducible  random-number 
streams.  A  feature  that  aids  in  this  is  the  provision  of  multiple 
streams  of  pseudorandom  numbers.  Having  more  than  one  stream  enables 
parts  of  a  model  to  operate  independently,  as  far  as  data  generation 
is  concerned,  and  not  influence  other  parts.  For  example,  when  studying 
decision  rules  for  ssslgnlng  men  to  jobs,  one  does  not  want  to  influence 
the  generation  of  Jobs  inadvertently.  Multiple  pseudorendom  number 
streams  Increase  a  progracner 'a  control  over  a  modal. 

On.?  also  wants  to  be  able  to  control  the  generation  of  random 
numbera  If  doing  ao  can  raduce  the  variability  of  simulation  generated 
performance  ffgurv.c.  For  example.  It  la  always  dealrablc  to  make  the 
variance  of  the  estimate  of  tna  average  length  of  a  waiting  line  within 


a  ainulntlon  model  aa  small  aa  possible.  The  reduction  of  sample 
variance  is  a  statistical  rattier  than  a  progranaaing  problem  in  all  but 
one  respoct;  a  progra.^mer  should  be  able  to  control  the  generation  of 
pseudorandom  numbers  if  this  is  required.  One  known  way  to  reduce 
variance  is  to  use  antithetic  variates  in  separate  simulation  runs; 
this  I'.s  discussed  in  [20]  .  As  the  generation  of  a  stream  of  ariates 
that  ire  antithetic  to  a  given  stream  involves  no  more  than  a  simple 
subtraction,*  this  feature  should  be  present  In  an  SPL. 

.'able  6  auimarizes  the  minimum  statistical  sampling  features  an 
SPL  should  have: 


Table  6 

STAliSTICAL  SAMPLING  FEATURES 

Pseudorandom  number  generation 
Multiple  random-number  streams 
Antithetic  variates 

Sampling  from  empirical  table  look-up  distributions 
Sampling  from  theoretical  statistical  distributions 


DATA  COLLECTION.  ANALYSIS.  AND  DISl 


The  performance  of  a  timulated  system  can  be  studied  In  several 
ways  [34].  The  dynamics  of  the  system's  behavior  can  be  traced  by 
looking  at  plots  of  relevant  simulation  va;  Ijbles  at  they  change  over 
time.  The  aggregaie  performance  can  be  studied  by  looking  at  statis¬ 
tical  analytes  of  simulation  generated  data;  means,  variances,  minima, 
maxima,  and  histograms  ire  usually  produced  for  such  suauaarlet . 

Ideally,  an  SPL  should  automatically  produce  all  data  collection, 
analysis,  and  display.  Unfortunately,  this  cannot  always  be  done,  since 
format  requirements  differ  among  organizations,  and  display  media  vary; 
what  is  possible  on  a  plotter  may  not  be  possible  on  a  line  printer  or 
a  typewriter.  Also,  efficiencies  are  gained  if  certain  data  are  not 
analyzed.  There  is  no  virtue  in  producing  frequency  counts  of  variables 
that  are  not  of  direct  interest  to  a  simulation  experimenter. 


If  r  ta  a  generated  ptaudorandon  number,  its  antithetic  variate 
is  1  -  r. 
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There  ace  several  topics  to  discuss  in  this  general  area;  how 
data  collection  is  specified,  what  data  collection  facilities  should 
be  provided,  how  display  media  can  be  used,  how  dis  pi  ay  fo,  .a  are 
specified,  and  what  data  analyses  should  be  performed. 

Data  Collection  Specification 

The  best  one  can  say  of  a  data  collection  specification  is  that 
it  is  unobtrusive.  While  data  collection  is  necessary,  statements  that 
collect  data  are  not  per  se  part  of  a  simulation  model's  logic  and 
should  not  obscure  the  operations  of  a  model  in  any  way.  People  find 
that  debugging  is  difficult  enough  without  having  to  deal  with  errors 
caused  by  ststements  intended  only  to  observe  the  behavior  of  a  model. 

The  ultimate  in  unobtrusiveness  is  to  have  no  specification 
statements  at  all.  Being  free  from  them  clearly  eliminates  any  diffi¬ 
culties  they  may  cause  when  reading  or  debugging  a  simulation  program 
code.  Unfortunately,  having  no  specification  at  all  means  that  every 
possible  piece  of  data  must  be  collected  in  every  possible  way,  at  the 
risk  of  neglecting  to  collect  something  an  analyst  may  want.  In  small 
models  this  is  probably  worthwhile.  In  large  models  it  can  lead  to 
■nacceptablc  increases  in  core  storage  requirements  and  program  running 
times.  GPSS  collects  certain  data  automatically  and  allows  a  prograosaer 
to  collect  other  data  himself;  GASP  does  something  similar. 

A  reasonable  alternative  is  a  linguistically  natural  set  of  data 
collection  statements  that  can  be  applied  globa'Iy  to  a  oxide  1  .  Being 
linguistically  natural,  they  will  be  easy  to  use  and  cleerly  differ¬ 
entiable  from  other  types  of  prograoming  statements.  Being  globally 
applicable,  they  need  be  written  only  once,  rather  than  at  each  place 
a  particular  item  of  data  to  be  collected  appears. 

Barring  this,  data  can  be  collected  through  explicit  procedural 
piogram  statements.  Data-col lection  specification  statements  of  this 
Sort  are  no  different  from  nomsl  variable  assignment  statements  nr 
subroutine  calls.  They  arc  the  easiest  to  implement  In  an  SPL,  but 
the  sioat  obtrusive  and  difficult  to  deal  with.  Host  SPLs  provide 
facilities  of  this  kind.  SIKSCRIFT  II  [39]  has  a  capability  for  global 
data-collection  specification. 
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DaCa  Collection  Facllitita 

One  must  be  able  to  collect  a  variety  of  data,  since  one  should 
be  ;llc  to  compute  all  the  statistics  an  analyst  might  want  about  a 
simulation  variable.  This  Includes  counts  of  Che  number  of  times  a 
variable  changes  value,  suras,  sums  of  squares,  maxima  and  minima  of 
these  values,  histograms  over  specified  intervals,  cross-products  of 
specified  variables,  time-integrated  sums  and  sums  of  squares  for  time- 
dependent  data,  and  time  series  displays.  Simulation  is  a  statistical 
tool,  and  statistically  useful  data  are  required  to  use  it. 

Naturally,  some  data  are  easier  to  collect  than  others.  Table 
7  lists  the  minimum  data  one  should  be  able  to  collect. 

Table  7 

D.^TA  COLLECTION  FEATURES 

Number  of  observations,  maxima,  and  minioia  for  all  variables 
Sums  and  sums  of  squares  for  time-independert  variables 
Time-weighted  sums  and  sums  of  squares  for  time-dependent  variables 
Variable  valua  histograms  for  time-independent  variables 
Tlme-ln-stdte  histograms  for  time-dependent  variables 
Time  series  plots  over  specified  time  Intervals 

These  data  should  be  easily  collectable  with  specialized  ttatements. 

One  should  be  able  to  collect  any  other  data  without  extreme  difficulty. 

An  important  feature  of  an  SPL  is  that  it  allow  reasonably  free  access 
to  all  model  data. 

Data  Analysis 

One  should  not  have  to  program  the  analysis  of  data  for  standard 
statistical  calculations,  such  as  Che  computations  of  means  and  variances. 
If  global  specifications  are  employed,  names  attached  to  atacistical 
quantities  should  invoke  calculations  when  the  names  are  mentioned.  If 
data  collection  statements  are  used,  standard  functions  should  operate 
on  named  data  to  compute  the  necessary  quantities. 

Table  d  chows  the  minimum  analysis  one  should  be  able  to  perform 
from  collected  data.  If  the  data  arc  present,  one  would  also  like  to 
have  functions  that  compute  correlation  coefficients  and  spectra  [21], 
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Table  8 

DATA  ANALYSIS  FEATURES 


Means 

Variances  and  standard  deviations 
Frequency  distributions 


Display  Media 

Standard  statistical  Information  Is  easily  printed  on  typewriters 
and  line  printers.  Time  series  plots  and  histograms  are  enhanced  by 
graphic  display.  As  this  type  of  Information  derives  inost  of  Its  Impact 
from  visual  observation,  there  Is  little  reason  It  should  not  be  pre¬ 
sented  this  way.  Advanced  SPLs  should  have  routines  for  charting 
results,  either  by  simulating  a  plotter  on  a  line  printer  or  by  dis¬ 
playing  results  directly  on  a  plotter  [13],  [23],  [62]. 

Today,  with  a  growing  number  of  large-scale  computing  systems 
making  use  of  cathode  ray  tube  displays  (CRTs),  these  devices  are  being 
used  more  and  more  for  displaying  simulation  output  [54].  Two  situa¬ 
tions  lend  themselves  to  CRT  application. 

In  the  first  situation,  the  CRT  Is  used  only  to  produce  attrac¬ 
tively  formatted  graphs  and  reports.  The  device  Is  not  viewed  on-line; 
pictures  are  made  and  used  In  lieu  of  printed  reports.  There  Is  no 
doubt  that  programmers  car.  use  enhanced  graphical  capabilities  If  given 
the  opportunity.  Generally,  no  changes  need  be  made  to  a  SFL  to  let 
then  do  so,  other  than  providing  access  to  general  system  software 
routines.  To  be  specific,  a  prograosner  should  be  able  to  call  upon 
library  plotting  routines  from  a  SlHSCRIPT  or  GPSS  program. 

The  second  situation  Is  the  more  glaosorous,  with  output  produced 
on-line  as  a  program  Is  executed.  Given  a  language  and  an  operating 
system  that  lets  a  programmer  Interrupt  a  running  program,  alter  system 
parastetcrs  and  variables,  and  then  continue  simulating  where  he  left 
off,  an  entirely  new  type  of  simulation  debugging  and  experlsientat Ion 
Is  possible.  This  type  of  Interactive,  adaptive  dialogue  between  model 
and  programmer  makes  on-line,  evolutionary  model  design  possible,  changes 
the  economics  of  sequential,  optimum-seeking  experimentation,  and  adds 
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a  valuable  dlmenrlon  to  program  debugging.  Several  reaearchers,  at 
The  RAND  Corporation  and  elsewhere,  are  currently  working  In  this  area 
[17],  [30]. 

Specification  of  Dlaolav  Formate 

There  are  probably  as  many  types  of  output  stateiDenta  as  there 
are  people  who  write  progrannlng  languages.  Each  type,  being  a  little 
different,  emphasises  one  or  more  aspects  of  output  control  at  the 
expense  of  others.  Styles  range  from  no  specification  at  all  (GPSS), 
through  format- free  statements  (SIMSCRIPT  II)  and  formatted  statements 
(CSL),  to  Special  report  forma  (SIHSCRIFT) .  There  are  times  when  each 
Style  has  Its  merits,  and  a  fully  equipped  SPL  will  have  a  variety  of 
output  display  statements. 

Four  types  of  display  atatemcnta  that  exist  In  present-day  SPl.a 


1  ! 


(1)  Automatic  output  in  a  standard  format  (GPSS,  GASP); 

Is  a  tlme-aaver  for  the  prograasner  and  e  boon  In  reasonably 
small  models  where  all  data  can  be  displayed  at  a  reasonable 
cost . 

Does  not  force  a  beginning  simulation  programmer  to  deal 
explicitly  with  output. 

Is  only  as  good  as  the  exhaustiveness  of  its  contents  . 

Is  oftsn  unsatisfactory  for  foriul  reports,  forcing  subse¬ 
quent  typing  and  graph  preparation. 

(2)  Format-free  output  (SIMSCRIPT  II): 

Enables  a  programmer  to  control  the  dleplay  of  Information 
without  regard  for  formats. 

Is  adequate  only  if  it  covers  ell  the  data  atructures  in  a 
language . 

la  most  useful  for  debugging,  error  message  reporting,  and 
printing  during  program  checkout. 

(3)  Formatted  output  (CSL); 

Requires  the  most  programmer  knowledge,  but  provides  the 
ataxlBum  control  of  Infonutlon  display. 

Is  traditionally  the  most  difficult  part  of  many  programming 
languages.  Insofar  as  the  grsatsat  nuaibar  of  atrora  are  made 
by  novice  programatra  In  format  atatsmants . 
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(4)  Beport  Generator:  (SIMSC&1.PT,  GST): 

Are  the  edlesc  way  ot  producing  specially  designed  reports. 

Must  have  a  complete  complement  of  control  facilities  to 
cover  all  report  situstions. 

Can  be  a  nuitance  to  use  In  very  simple  situations. 

Usually  geni;r.3te  an  oxtretnely  large  amount  of  object  code. 

Are  efficient  from  a  programming  standpoint,  but  not  from 
a  core-consumption  point  of  view. 

Since  the  production  of  reports  is  the  primary  taak  of  all  pro¬ 
grams,  whether  they  are  run  for  checkout,  for  display  of  computed 
results,  or  for  preparation  of  elaborate  management  reports  and  charts, 
a  good  SPL  should  contain  ata tetmenta  adapted  to  all  display  situations. 
Going  back  to  the  discussion  of  data  collection,  a  programmer  should 
not  have  to  spend  s  great  deal  of  his  time  writing  output  statements. 

He  should  be  able  to  concentrate  on  model  construction  and  programming 
and  not  have  to  dwell  at  length  on  conventional  output  taska  .  He 
should  be  able  to  spend  time  on  sophisticated  output  statesients,  how¬ 
ever,  Co  produce  displays  that  are  unusual  or  Chat  deal  with  exotic 
display  devices. 

MONITORING  AND  DEBUGGING 

T'vo  essential  requirements  of  all  SFLs  can  be  served  by  the  same 
set  of  prograraalng  facilities.  SPLs  should  be  able  to  assist  in; 

(1)  Program  debugging;  and  in 

(2)  Monitoring  system  dynamics. 

Debugging  can  be  difficult  in  high-level  progranxning  languages, 
as  there  is  generally  a  great  deal  of  difference  between  source  and 
object  codes.  Errors  can  be  detected  during  compilation  and  execution 
that  are  only  distantly  related  to  source-language  comotands.  Moreover, 
when  an  SPL  is  translated  into  an  intermediate  POL,  as  was  originally 
done  in  SIMSCRIFT  and  CSL,  execution  error  measages  are  often  related 
to  the  intermediate  language  end  not  the  programmer's  source  atatetaencs. 
These  messages,  while  meenlngful  to  an  expert,  can  mislead  a  novice 
SPL  programmer. 

Debugging  is  also  difficult  because  the  flow  of  control  in  a 
almulatlon  is  stochcif^lcal  ly  determined.  Moreover,  it  can  be  difficult 


to  obtain  a  record  of  the  flow  of  control,  since  an  SPL-designed 
"Cialng  routine"  or  other  forn  of  control  prograia  la  the  originating 
point  for  all  event  calls.  In  some  language*,  it  1*  iaposaible  to  do 
so  .  Without  program  flow  information,  and  information  about  the  system 
state  at  various  times,  some  simulation  program  errors  can  be  found 
only  by  luck. 

The  debugging  feature*  an  SPL  should  provide  are  listed  in  Table  9. 


Table  9 

DEBUGGING  FEATURES 

Report  compile  and  execute-time  errors  by  source 
statement  related  messages; 

Display  complete  program  flow  status  when  an  execute- 
time  error  occurs.  This  means  displaying  the  entry 
points  and  relevant  parameters  for  all  function  and 
subroutine  calls  in  effect  at  the  time  of  the  error; 

Provide  access  to  control  information  between  event 
executions.  This  allows  event-tracing  during  all  or 
selected  parts  of  a  program,  and  use  of  control 
inforsiation  in  program  diagnostic  routines. 


These  same  facilities  arc  needed  for  mcnitorlng  system  dynamics. 
As  one  use  of  sinulatlon  is  the  study  of  system  behavior,  one  aust  be 
able  to  view  sequences  of  events  and  their  relevant  data  to  observe 
system  reactions  to  different  inputs  and  different  system  states. 
Event-tracing  is  an  important  tool  for  this  kind  of  study. 

In  an  event-oriented  SPL,  debugging  and  monitoring  features  will 
undoubtedly  be  implemented  differently  from  the  same  or  similar  fea¬ 
tures  in  activity-  or  process-oriented  SPLs.  This  is  not  important. 
The  basic  issue  is  whether  some  basic  fscillty  exists  for  assisting 
in  program  debugging  and  for  doing  program  monitoring. 


INITIAUZATION 


Because  simulation  Is  the  movement  of  a  system  swdel  through 
simulated  time  by  changing  its  state  descriptions,  it  is  important 
that  sn  SPL  provlda  s  convsnlent  sMchsnism  for  spsclfylng  inltisl 
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syatem  aCatea.  In  alnulatlona  dedicated  to  atudylng  atart-up  or 
tranalent  condltlona,  a  convenient  toechenlam  for  doing  thla  la  aumda- 
tory;  In  almulatlona  that  only  analyze  ateady-atate  syaten  performance. 

It  la  atlll  neceaaary  to  atart  off  at  aome  feaalble  ayatem  configuration. 

Some  SPLa  atart  almulation  In  an  "empty  and  Idle  state"  aa  their 
normal  condition  and  require  special  efforta  to  establish  other  con¬ 
ditions.  They  rely  either  on  standard  Input  statements,  formatted  or 
unformatted,  to  read  In  data  under  program  control  or  on  preliminary 
programs  that  set  the  system  In  a  predetermined  state. 

An  alternative  to  these  procedures  la  a  special  form  that  reduces 
the  Initialization  task  to  filling  out  a  form  rather  than  writing  a 
program.  While  adequate  In  a  laige  number  of  situations,  this  alter¬ 
native  suffers  from  being  inflexible.  As  with  the  preparation  of 
simulation  reports,  the  correct  anrwer  Ilea  In  a  atixture  of  Initial¬ 
ization  alternatives. 

Another  aspect  of  Initialization  la  the  ability  to  save  the  state 
of  a  system  during  a  simulation  run  and  reinitialize  the  system  to 
this  state  at  a  later  time.  This  facility  is  crucial  In  the  simula¬ 
tion  of  extremely  large  systems,  and  In  conducting  sequential  exper¬ 
iments.  One  should  be  able  to  save  all  the  information  about  a  program, 
including  relevant  data  on  the  atatus  of  external  storage  devices  and 
peripheral  equipment,  and  restore  It  on  command  at  a  later  date. 

OTHER  FEATURES 

There  are  a  number  of  non-operatlonal  features  that  must  be  taken 
into  consideration  when  designing  or  selecting  an  SPJ, .  A  manager  or 
analyst  Is  interested  in  program  readobl itty;  communication  of  the 
structure,  assumptions  *nd  operations  of  a  luodel  is  Important  if  the 
model  is  to  be  used  correctly.  A  manager  Is  also  Interested  in  execu¬ 
tion  efficiency;  simulations  cea  reqaira  large  numbers  rf  ■experlmsntsl 
runs,  and  the  cost  par  run  o?jst  be  low  enough  to  make  o  project  eco¬ 
nomical.  On  the  other  hand,  s  manager  must  baloace  the  costs  of  pro¬ 
ducing  a  program  agalnat  ptugrat^  cxceutlou  costs.  Complex  EioaeMng 
languages  may  compile  and  execute  less  efficiently  than  simpler 
languages,  but  they  make  proMcas  solvable  In  a  shorter  period  of 
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time.  If  total  problem  aolvlng  time  la  Important  rather  than  computer  1 

time  cotta,  the  evaluation  criteria  change.  ; 

SPL  documentation  la  Important  to  applications  and  ayatem  pro-  j 

graumeru.  An  appllcatlona  programmer  needs  a  good  IneCructlon  otanual 
to  learn  a  language  and  to  uae  aa  a  reference  guide.  Aa  an  SFL  becomes 
more  complex  the  need  for  good  documentation  Increaaea .  Syetema  pro- 
graantera  need  documentation  to  be  able  to  maintain  an  SPL.  This 
documentation  muat  allow  them  to  Install  the  language  In  the  computing 
system;  with  today's  complex,  hand-tailored  systems  tliia  Is  becoming  i 

more  difficult.  It  muat  also  provide  enough  Information  for  them  to 
make  modifications  In  the  SPL  itself  as  translator  errors  are  dis¬ 
covered.  It  Is  less  Important  that  uaers  be  able  to  modify  an  SPL, 
either  to  change  the  form  of  statements  or  to  add  new  ones,  but  this 
can  be  an  Important  consideration  In  certain  Instances.  Some  languages 
In  fact  are  designed  to  do  this  easily  [l6],  [38],  [SO]. 


HiualUI. 
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IV.  SOME  EXAMPLES  OF  SPLS 


This  section  illustrates  four  SPLa;  SIMSCRIPT  II,  an  cvent- 
orienced  language;  SIMULA,  a  process-oriented  language;  CSL,  an 
activity-oriented  language;  and  GPSS,  a  tranaactinn-orientcd  language.* 
With  the  exception  of  the  SIMSCRIPT  II  example,  which  appears  for  the 
first  time  in  this  Memorandum,  the  illustrations  are  taken  from  pub¬ 
lished  descriptions  of  the  respective  languages.  The  examples  differ 
in  detail  and  specificity,  but  are  nevertheless  representative  of  the 
concepts  the  languages  employ.  As  they  have  been  taken  from  other 
sources  with  only  a  surface  editing,  they  also  differ  greatly  in  style 
and  format  . 

Because  the  SIMSCRIPT  II  example  was  written  especially  for  this 
Meraorandum,  it  is  the  most  detailed  and  Illustrates  the  greatest  number 
of  features.  Consequently,  the  reader  may  tend  to  Judge  SIMSCRIPT 
II  a  auperior  language.  He  should  not  make  such  a  Judgment  solely  on 
the  basis  of  these  examples.  Ideally,  they  should  all  be  comparable 
and  not  bias  the  sought-after  end,  which  is  the  explication  of  their 
different  approaches  to  providing  the  SPL  features  discussed  in  Sec. 
III.  We  can  only  hope  that  our  inability  to  procure  "equally  repre¬ 
sentative"  examples  will  not  detract  from  our  purpose. 

The  concepts  the  languages  employ  have  all  been  described  In 
previous  sections  and  readers  should  be  able  to  follow  the  examples 
without  a  thorough  understanding  of  each.  The  format  of  the  following 
subsections  Is:  description  of  a  model,  simulation  program  for  the 
model,  discussion  of  the  program. 

SIMSCRIPT  II:  AN  EVENT-ORIEKTED  LANGUAGE 

The  model  used  in  this  example  It  the  "executive-secretary  system" 
described  in  [3^].  The  program  conforms  as  closely  as  poeslble  to 
the  description  given  in  [34]  and  the  flowcherts  of  Its  events. 

★ 

Although  GPSS  la  proceaa-orlcitted.  In  the  eenae  that  Ita  modela 
take  e  aynoptlc  view  of  ayatema,  Ita  basic  orientation  la  with  the 
flow  of  trantacClona  rather  than  the  occurrance  of  procesaes. 
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The  Model 

VFe  88SUM  that  executlvea  in  an  office  •yatem  have  two  types  of 
tasks:  they  process  Incooilng  c.oaxaunlcatlons  (invoices,  requests  for 
bids,  price  queries)  and  handle  interoffice  correspondence.  The  tasks 
are  not  independent  of  one  anotner;  the  former  are  produced  by  mecha- 
nisms  external  to  the  office  system,  the  latter  arise  outing  daily 
operations.  As  they  result  in  similar  actions  we  can  treat  both  the 
sane  way,  through  an  event  that  "discovers"  a  task.  Other  events 
assign  tasks  to  secretaries,  schedule  coffee  breaks  and  departures 
for  lunch,  and  handle  the  review  of  completed  secretarial  tasks. 

Table  10  lists  the  objects  that  "live"  in  the  office  system  --  which 
we  shall  call  entities  from  here  on  --  and  their  attributes. 

Table  10 

SYSTEM  ENTITIES  AND  THEIR  ATTRIBUTES 

Executive 

Position : 

hansger 

Senior 

Junior 

State: 

Busy 

Available 

On  break 


Given  the  s'.etlc  structure  defined  in  Table  10,  the  nature  of 
the  task-discovery  event,  and  soBxe  logic  not  yet  described,  we  can 
construct  a  flowchart  oudel  of  the  actions  that  cake  place  when  a 
request  enters  the  system.  This  aodel  is  illustrated  in  Fig.  4. 
Numbers  to  the  left  or  each  flowchart  block  refer  to  comaenta  in  the 
body  of  the  text  that  describe  the  operations  that  take  place  within 
Che  block.  The  SI16CRIPT  II  program  for  the  model  follows  the 
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flowchart*  and  their  deacriptlon.  The  flowcharts  and  their  reepective 
programs  differ  sumewhat  as  the  flowcharts  are  simplified  for  tho  salte 
of  clarity. 

Block  1  is  the  entry  point  to  the  flowchart.  It  contains  a  name 
chat  will  be  used  in  subsequent  flowcharts  to  refer  to  the  "task 
request"  event.  The  directed  arrow  leading  from  it  Is  a  symbol  com¬ 
monly  used  to  indicate  a  path  and  direction  of  flow. 

Block  2  is  a  decision  block  that  splits  the  logical  flow,  depending 
on  the  kind  of  request  that  has  Just  occurred.  To  understand  how  this 
block  operates  we  must  understand  the  concept  of  an  event  occuirence. 

An  event  occurs  when  its  "time  arrives,"  the  time  having  been 
previously  recorded  by  an  internal  scheduling  block  oi  observed  on  an 
input  data  card.  The  preclPe  (.•echaniso  that  ccconpliahes  these  tasks 
need  not  be  stated  here.  It  suffices  if  the  reader  understands  that 
there  i«  some  mechanism  operating  in  the  background  of  the  sioulatlon 
program,  obsfc.  1 '.g  data  cards  and  previously  scheduled  events,  ordering 
them  by  their  event  times,  end  "popping  them  up"  when  their  time 
arrives.  This  In  fact  is  the  function  of  the  event  selection  block 
(Block  B) .  The  resder  will  notice  that  every  event  terminates  with 
an  event  selection  block.  It  iv  in  event  selection  blocks  that  time 
discrimination*  are  made,  events  selected,  end  the  sioulation  clock 
advanced . 

When  a  request  event  is  popped  up,  the  sloulstion  prog, .am  has 
access  to  information  associated  with  it,  e.g.,  how  it  was  caused. 

The  aiodcL  is  able  to  look  at  this  infoination  and  take  action  on  it. 

If  the  request  is  for  an  internally  generated  task,  the  flowchart 
leads  d  -ectly  to  Block  S,  where  a  question  is  arkt  I  to  see  if  office 
workers  are  available  to  process  Che  request.  If  the  request  is  for 
on  exvcmilly  geneiatcd  task,  the  prograoi  pauses  in  Blocks  'j  and  4  to 
read  information  about  the  next  arrival  from  an  extamsl  data  aourcc, 
and  sch'dule  ita  snivel  at  seme  future  time.  Mien  It  does  so  it 
records  s  memo  of  a  request  ariival  and  its  time  on  a  calendar  of 
events  scheduled  to  occur.  This  calendar  Is  part  of  the  selection 
trec.ipnism  e^iployed  in  sequencing  events  and  advancing  aiinulati'^n  time. 
Thaas  opcratlona  are  performed  by  Che  SltC'JRlPT  II  system  and  do  not 
havt  to  be  programsstd  axpllcitly. 


By  the  time  the  program  arrives  at  Block  S,  It  it  through  with 
scheduling  future  events  and  is  concerned  with  processing  the  request 
that  has  just  arrived.  Since  real  offices  do  not  work  continuously, 
but  pause  for  lunch  and  coffee  breaks  during  the  day,  the  model  asks 
if  such  a  period  is  in  progress.  If  it  is,  the  request  cannot  be 
processed  imn^diately  but  must  be  tiled  for  later  handling.  If  the 
request  can  be  processed.  Block  6  transfers  control  to  a  routine  that 
does  so.  The  routine  will  return  to  the  request  event  when  it  finishes 
processing  the  task. 

Block  7  records  a  request  that  cannot  be  handled  in  a  backlog 
file;  it  might  be  an  in-basket  in  real  life.  The  file  entry  is  nade 
an  that  when  the  office  workers  return  to  their  desks  they  see  the 
tasks  that  accumulated  while  they  were  gone. 

Block  B  directs  the  simulation  program  to  select  an  event  from 
the  time-ordered  file  of  scheduled  events.  It  might  be  another  request 
or  the  completion  of  a  previous  task.  When  the  next  event  is  selected, 
it  may  or  may  not  Indicate  a  simulation  time  advance.  If  It  does  not. 
we  think  oi  it  and  the  event  just  completed  as  occurring  sloiulcaneous’y; 
although  they  are  processed  in  series  on  the  computer,  there  is  no  time 
advance  and  they  are  considered  as  happening  at  the  same  time. 

Initiating  c  Task 

Once  the  system  lias  accepted  a  request,  n  nwitch  must  be  made 
between  it  and  the  resources  needed  to  llll  it.  A  routine  is  written 
to  do  this;  its  logic  Is  shown  in  Fig.  First  a  search  Is  made  for 

an  executive.  If  one  Is  found  who  Is  free  and  can  handle  the  request, 
a  secretary  is  procured  if  needed. 

Block  1,  at  always.  Is  on  entry  block  giving  the  symbolic  name 
of  the  routine. 

fllnck  2  starts  the  match  between  a  task  and  its  resources  by  asking 
if  the  request  Just  entered  calls  for  a  particular  executive,  e.g., 
there  has  been  o  rslephone  call  for  a  certain  person  or  a  request  for 
a  price  quotation  from  a  specialist  <n  a  certain  area.  If  no  particular 
executive  is  called  lor.  Block  I  passes  ftow  to  Block  .1,  where  an  exec¬ 
utive  is  seiectea.  li  a  certain  person  is  requested,  flow  proceeds  to 
Block  i*,  where  a  test  Is  made  to  see  if  this  perean  is  available. 
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Block  3  Is  typical  of  a  functional  block  whose  descilptlon  is 
short  but  whose  prograssalng  content  might  be  large.  A  procedure  to 
select  an  executive  can  be  brief,  e.g.,  managers  can  do  everything, 
senior  executives  can  do  everything  except  give  price  quotations, 
junior  executives  can  only  answer  the  telephone;  or  It  can  be  long 
and  elaborate,  e.g.,  an  executive  Is  selected  whose  personal  qualifi¬ 
cations  as  listed  in  his  personnel  file  toatch  the  requirements  of  the 
task  according  to  a  complex  and  computationally  Intricate  formula. 

Many  of  a  simulation  model 'a  key  assumptions  are  built  Into  blocks 
such  as  this . 

When  an  executive  Is  selected,  Block  3  transfers  to  Block  4,  the 
block  to  which  control  Is  passed  If  a  p^irtlcular  executive  is  called 
for . 

Block  4  asks  If  the  executive  requested  In  Block  2  or  selected 
In  Block  3  la  available.  It  does  so  by  examining  the  executive's  state 
(status  code);  If  the  code  is  "available,"  the  executive  Is  free  to 
handle  the  request,  If  it  Is  "bufy"  or  "on  break,"  he  Is  not.  Once 
again,  as  In  Block  ' ,  Che  flow  logic  lo  split  depending  on  the  answer 
to  this  question. 

If  Che  selected  executive  Is  avall<ible,  flov?  passes  to  Block  6, 
where  processing  of  the  task  continues.  Before  we  consider  these 
actions  we  should  discuss  what  happens  If  the  executive  is  not  available. 

Block  3  aska  if  a  subttltute  Is  available  for  a  buay  executive, 
implying  that  a  aubstltutlon  can  be  made  and  that  a  procedure  exlsta 
for  finding  one.  This  situation  is  a  llttU  like  that  of  Block  3, 
where  .in  executive  jii  selcctitd  for  a  particular  type  of  taak.'  Block 
5  could  i)e  expanded  i.o  a  serlea  of  blocka  describing  a  procedure  for 
selecting  a  substitute,  tcktlng  for  hli  avsl labl  .Ity,  selecting  another 
substitute  if  necessary,  and  so  on  until  all  poaslblc  candldstea  ace 
tried  a'^d  accepted  or  mjccccd.  In  our  simplified  model  we  do  not  do 
this.  We  only  Indicate  that  If  a  substitute  cennot  be  found,  control 
passee  to  Block  6,  which  filet  the  unprocessed  task. 

Block  6  of  this  event  le  Identlcel  to  Block  7  of  tlie  requeet  event; 
It  .l}<ts  Inforouitlon  about  the  request  for  Istet  processing.  7. .Is  block 
epniars  In  the  simulation  model  whenever  a  request  cannot  be  processed 
and  asist  bs  "rseeabtrad ." 
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In  Blo<.-  7  control  le  pataad  vta  an  event  aeiettloa  block  back 
to  t.l»e  "kluekeepinfc."  aethanlao  ol  tbc  alaa'lation  program.  Since  the 
ri'rrent  requanr  cannot  be  proceased,  tht  'oodel  muoc  look  at  Ita  calen¬ 
dar  of  scheduled  evcnta  to  determine  what  to  do  next. 

Returning  to  the  case  where  an  executive  la  available  to  process 
a  request,  we  ask  next  In  r^lock  8  If  a  'secretary  )s  alac  needed.  She 
will  be  if  the  request  la  for  dictation  or  for  socoe  task  where  Instruc¬ 
tions  nust  be  given;  she  will  not  be  If  the  task  Is  slnqtly  answering 
a  telephone  call.  This  question  can  be  answered  In  a  number  of  ways 
in  an  operating  computer  prograoi;  as  with  most  questions  of  this  type, 
we  leave  the  description  of  decision-making  at  the  macro  level,  namely, 
that  a  decision  has  to  be  made. 

Block  9  starts  the  flow  path  for  the  case  where  a  request  can  be 
honored  by  an  executive  alone;  It  decemlnet  the  aioount  of  time  he 
will  spend  on  the  task. 

block  10  puta  the  executive  In  a  "busy"  state  so  that  he  cannot 
be  called  on  tr  do  another  task  while  he  Is  working  on  this  one.  He 
will  remain  In  this  state  until  the  "executive  available"  event  occurs; 
this  is  scheduled  in  Block  11  to  happen  after  the  lapse  of  the  pre¬ 
viously  determined  emount  of  time. 

Before  proceeding  with  the  slnulatlon,  the  model  must  ask  if  pro¬ 
cessing  this  task,  e.g.,  answering  a  phone  call.  Induces  another  task, 
e.g-,  writing  a  memo  .  This  Is  done  in  Block  12.  If  c  Cask  Is  not 
Induced,  flow  passes  Co  Block  7,  where  Che  ax>dcl  Is  Instructed  to 
select  another  event  and  proceed  with  the  slaxilatlon.  If  a  Cask  Is 
induced.  Block  13  determines  Its  characteristics  and  passes  them  on 
to  Block  14,  where  the  Induced  cask  is  scheduled  to  be  requested. 

Flow  Chen  proceeds  to  Block  7. 

If,  back  In  Block  8,  we  found  that  a  secretary  waa  needed  to  work 
along  with  the  executive,  control  would  have  passed  to  Block  15,  where 
a  aecretary  laust  be  selected  before  a  task  starta .  This  logic  can 
pair  a  particular  secietary  with  an  executive,  pool  all  secretaries 
So  that  they  are  available  Co  all  executives,  or  employ  rome  Immediate 
scheme.  As  was  done  In  selecting  an  executive,  when  a  aecretary  is 
chosen,  her  status  code  nuot  be  tr;sced  to  sec  If  she  Is  available. 
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Block  16  performs  this  rest.  Like  Block  6,  It  cen  be  considered 
a  macro  block  In  which  alternatives  and  availabilities  are  tested 
until  a  decision  is  reached.  If  a  secretary  is  not  available,  a 
request  cannot  be  processed  and  must  be  filed  along  with  other  unpro¬ 
cessed  requests. 

Once  a  secretary  Is  found,  Blocks  17,  16,  and  19  determine  the 
time  the  executive  and  secretary  will  spend  on  the  Job,  put  the  secre¬ 
tary  in  the  "busy"  state,  and  schedule  the  time  when  her  work  will  be 
reviewed.  It  Is  not  necessary  that  the  executive  and  the  secretary 
work  together  on  the  task  for  the  same  period  of  time;  separate  events 
are  provided  to  schedule  choir  release  Irom  the  task  at  different  t  Isies , 
The  release  times  can  be  Che  same,  however,  If  the  task  le  a  cooper¬ 
ative  effort. 

Block  19  transfers  control  to  Block  10  after  completing  its  func¬ 
tion,  picking  up  at  a  part  of  the  flowchart  that  we  have  already  seen. 
The  reader  should  be  able  to  see  why  and  how  this  Is  done. 

Review  of  a  Secretarial  Task 

One  of  the  office  rules  Is  chat  every  task  a  secretary  performs 
must  be  reviewed.  When  a  secretary  finishes  a  task  she  brings  It  to 
the  attention  of  Che  executive  who  Initiated  It.  If  he  is  not  avail¬ 
able,  she  waits. ^  If  he  Is  available,  he  reviews  the  work  and  either 
accepts  it  or  notes  corrections  that  must  be  made  before  another  review. 
The  Logic  ot  the  review  event  is  shown  In  Fig.  6. 

Block  1,  as  usual,  nas  a  the  event.  Block  2  aska  a  queatlon  about 
executive  availability  transfers  to  Block  3  or  5,  depending  on 
the  answer. 

Block  3  records  the  review  task  In  the  cask  backlog  file  if  the 
executive  is  busy.  The  task  Is  filed  along  with  incoming  requests 
that  were  filed  for  reasons  we  saw  In  previous  flowcharts.  Block  4 
calls  OR  Che  simulation  timing  mechanism  to  select  the  next  scheduled 
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This  may  not  be  good  office  practice,  but  Is  a  feature  of  our 
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event .  The  secretary  is  not  atdgned  an  "available”  atate,  bur.  trenaina 
"busy,"  waiting  for  the  executive  to  become  free  and  revisw  her  work. 

block  5  Is  another  macro  block,  hiding  what  might  be  ni  enorrooua 
amount  of  logic  behind  the  label  "executive  review  of  aeci«:tary'8  work.*’ 
Block  6  branches  on  the  previously  computed  review  decision.  If 
the  Cask  has  been  dune  satisfactorily,  the  secretary  Is  scheduled  Co 
become  available  .Imnwdlatfily  (Block  9). 

An  unsat  Is  factory  task  has  Its  correction  clnie  computed  In  Block 
7  and  review  rescheduled  in  Klock  8 

Concerning  this  evert,  it  Is  important  to  note  its  hidden  basic 
asnunpticiis ;  a  review  cask  takes  no  tlice  and  a  secretary  stays  with 
a  job  until  it  gets  reviewed.  These  assumptions  can  be  easily  changed 
to  allow  secretaries  to  do  other  work  wliile  waiting  for  reviews,  cause 
executives  to  spend  time  making  large-scale  corrections,  and  no  on. 

Executive  Available  at  the  End  of  a  Task 

This  event  marks  the  completion  of  ar,  executive  activity.  It 
returns  an  executive  to  an  "/ivai lahle"  state  and  determines  his  next 
actron:  anothet  Cask,  a  break  for  coffee  or  lunch,  or  an  idle  (dis¬ 
cretionary  time)  period.  The  event  logic  is  shown  In  Fig.  7. 

Block  1  names  the  event.  Block  2  puts  Che  executive  In  an  avail¬ 
able  state  and  asks  questions  about  the  next  executive  actions.  These 
questions  are  asked  in  a  specific  order  and  imply  certain  things.  From 
the  logic  of  the  event,  we  see  that  a  lunch  or  coffee  break  cannot 
start  until  a  current  job  is  completed,  but  will  be  taken  when  it  is 
due  regardless  of  task  backlogs,  This  is  Important  as  It  assuiaes  a 
priority  sequence  imposed  by  toe  order  In  wlilch  questions  are  asked 
and  not  by  explicit  priority  stateiaentt. 

Block  3,  which  decides  if  a  break  is  due,  also  contains  hidden 
logic.  When  one  considers  the  connections  between  events  and  the  way 
in  whicli  the  model  ope.’-ates,  he  sees  that  if  an  executive  it  idle  (in 
the  "available”  state)  and  a  break  rime  occurs,  there  is  no  mschanlSB 
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thaC  alerts  him  of  this.  By  the  way  the  model  Is  constructed,  breaks 
can  be  taken  only  after  the  completion  of  Jobe.  This  will  have  little 
practical  effect  if;  (a)  the  work  rate  Is  high  In  the  office  so  that 
there  are  no  long  periods  of  Idle  time  possible,  or  (b)  the  logic  of 
Block  3  looks  ahead  and  atai'ts  a  break  early  if  one  la  almost  due. 

This  small  difficulty  has  been  put  In  the  model  to  acquaint  the  reader 
with  problems  that  can  occur  when  one  seta  out  to  build  a  model  from 
scratch . 

If  a  break  is  due  or  in  progress.  Block  4  places  the  executive 
In  the  "break"  state,  Block  5  determines  its  duration,  flock  6  sched¬ 
ules  the  executive's  return  to  an  availability  condition  (by  executing 
this  same  event  some  time  in  the  future  after  the  simulation  clock  has 
advanced  past  the  break  point),  and  Block  7  returns  control  tc  the 
event  selection  mechanism. 

If  a  break  is  not  due,  the  model  uuat  decide  whether  the  executive 
should  be  left  in  the  available  state  or  assigned  to  a  waiting  task. 

It  does  this  by  looking,  in  Block  8,  at  the  file  in  which  we  have  been 
putting  requests  that  could  not  be  proceaaed.  It  the  file  is  empty, 
the  executive  is  left  alone  and  control  is  passed  to  Block  7  to  select 
the  next  event. 

If  the  file  is  not  empty,  the  model  must  select  a  job.  If  there 
is  only  one  Job  In  the  file,  there  Is  no  problem.  If  there  is  more 
than  one,  there  Is  a  conflict  situation  that  must  be  resolved.  Con¬ 
flict  is  usually  ’esolved  by  priority  rules  that  assign  values  to 
different  types  of  Jobs;  a  Job  la  selected  that  has  the  highest  (or 
perhaps  lowest)  value.  In  cases  with  ties,  multiple  ranking  criteria 
are  used.  Possible  criteria  that  might  be  used  in  this  model  are; 
time  a  Job  arrives  in  the  system,  skill  level  required  to  process  a 
Job,  etc.  The  issue  of  selection  rules  is  complex,  and  a  model  that 
merely  says  "select  a  Job"  hides  a  great  deal  of  work  that  must  be 
done  to  develop  an  operating  model.  For  example,  few  organisations 
have  well-articulated  and  formalised  priority  rules,  and  a  modeler 
may  have  hia  hands  full  merely  trying  to  find  out  the  "rules  of  ths 
gsoe 
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Once  a  task  has  been  aelected,  however.  It  La  relatively  almple 
to  route  the  ex::cutive  :o  the  proper  flowchart  to  process  it.  This 
is  shovn  ir>  Blocks  10,  II,  and  12. 

Secretary  Available  at  the  End  of  a  Task 

This  event  ia  similar  to  event  3  in  both  its  intent  and  its  form. 
When  a  secretary  is  released  from  a  task,  she  becomes  available  and  is 
either  sent  on  a  break,  put  on  a  backlogged  Job,  or  left  idle,  depending 
on  current  conditions.  Blocks  1  through  10  in  the  flowchart  of  Fig.  8 
correspond  to  similar  blocks  in  Fig.  ?  and  need  not  be  commented  upon 
here . 


I 

I 

i 


i  --  Event  nuabcr  4:  evii  l<iblll  ty  of  a  secretary  at  the  end  of  a  tea 
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Thc  Program 


PREAMBLE 

NORMALLY  MODE  IS  INTEGER 
''DECLARATION  OF  STATIC  SYSTEM  STRUCTURE 
THE  SYSTEM  OWNS  A  REQUEST  .FILE  ' 

PERMANENT  ENTITIES.... 

EVERY  EXECUTIVE  HAS  A  POSITION  AND  A  STATE 
El'ERY  SECRETARY  HAS  A  STATUS 
EVERY  TASK. TYPE  HAS  A  TASK. TIME,  A  NEED,  AND 
AN  INDUCE. PROBABILITY 

EVERY  SECRETARY,  TASK. TYPE  HAS  A  SKILL. FACTOR 
DEFINE  TASK .TIME,  INDUCE. PROBABILITY  AND 
SKILL. FACTOR  AS  REAL  VARIABLES 
TEMPORARY  ENTITIES.... 

EVERY  TASK  HAS  A  WHO,  A  WHAT  AND  A  DELAY .TYPE 
AND  MAY  BELONG  TO  THE  REQUEST. FILE 
"DECLARATION  OF  DYNAMIC  SYSTEM  STRUCTURE 
EVENT  NOTICES  .... 

EVERY  REQUEST  HAS  AN  EXEC  AND  A  CLASS 
EVERY  REVIEW  HAS  AN  EX  AND  A  SEC 
EVERY  EXECUTIVE. AVAILABLE  HAS  AN  EXi 
EVERY  SECRETARY. AVAILABLE  HAS  A  SECl 
EXTERNAL  EVENTS  ARE  REQUEST  AND  END. OF .SIMULATION 
BREAK  REVIEW  TIES  BY  HIGH  EX  THEN  BY  LOW  SEC 

PRIORITY  ORDER  "OF  EVENTS"  IS  REQUEST,  REVIEW,  SECRETARY. AVAILABLE, 
EXECUTIVE. AVAILABLE  AND  END. OF. SIMULATION 
' 'OTHER  DECLARATIONS 

DEFINE  OFFICE. STATUS  AS  AN  INTEGER  FUNCTION 
DEFINE  INDUCE. TYPE,  SECRETARY. REQUIRED .CLASS  AND 
SUM. REQUESTS  AS  INTEGER  VARIABLES 
DEFINE  SATISFACTORY  AS  A  REAL  VARIABLE 
DEFINE  IDLE  TO  »;£AN  0 
DEFIKE  WOKkImG  TO  KEAN  1 
DEFINE  BREAK  TO  MEAN  2 

' 'DATA  COLLECTION  AND  ANALYSIS  DECLARATIONS 
ACCUMULATE  AVG. BACKLOG  AS  THE  MEAN  AND 

STD.BCKLOG  AS  THE  STD. DEV  OF  N. REQUEST, FILE, 

ACCUMUIATE  STATE. EST(0  TO  2  BY  l)AS  THE  HISTOGRAM 
OF  STATE 

ACCUMUIATE  STATUS, EST(0  TO  2  BY  1)AS  THE  HISTOGRAM 
OF  STATUS 

END 
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MAIN  ’ 'THIS  ROUTINE  CONTROLS  THE  GIMJLATION  EXPERIMENT 
INITIALIZE'  CALL  INITIALIZATION  "TO  ESTABLISH  THE  INITIAL  SYSTEM  STATE 
START  SIMULATION  "BY  SELECTING  THE  FIRST  EVENT 
' 'WHEN  SIMULATION  RUN  IS  ENDED  CONTROL  PASSES  HERE 
IF  DATA  IS  ENDED,  STOP 


OTHERWISE. . . ' 'GET  SET  FOR  ANOTHER  RUN 
UNTIL  REQUEST. FILE  IS  EMPTY,  DO 

REMOVE  THE  FIRST  TASK  FROM  THE  REQUEST. FILE 
DESTROY  THE  TASK 
LOOP 

GO  INITIALIZE  "FOR  THE  NEXT  EXPERIMENT 
END 


ROUTINE  FOR  INITIALIZATION 
READ  N. EXECUTIVE  CREATE  EACH  EXECUTIVE 

READ  N. SECRETARY  CREATE  EACH  SECRETARY 

READ  N. TASK. TYPE  CREATE  EACH  TASK. TYPE 

FOR  EACH  EXECUTIVE,  DO  READ  POSIT I ON (EXECUTIVE)  AND 
STATE(EXECUTIVE)  RESET  TOTALS  OF  STATE  LOOP 
FOR  EACH  SECRETARY,  DO 

READ  STATUS (SECRETARY)  RESET  TOTALS  OF  STATUS 

ALSO  FOR  EACH  TASK.TYPE,  READ  SKILL. FACTOR(SECRETARY,  TASK. TYPE), 
TASK. TIME(TASK. TYPE),  NEED (TASK .TYPE) , 

INDUCE. PROBABILITY (TASK.TYPE) 

LOOP 

READ  INDUCE. TYPE,  SECRETARY. REQUIRED. CLASS  AND  SATISFACTORY 

RESET  TOTALS  OF  N. REQUEST. FILE 

END 


REQUEST  GIVEN  EXEC  AND  CLASS  SAVING  THE  c.VZ:~ 

ADD  1  TO  SUM. REQUESTS  "COUNT  NUMBER  OF  TASK  REQUESTS 
IF  REQUEST  IS  EXTERNAL,  READ  EXEC  AND  CLASS  "FROM  A  DATA  CARD 
REGARDLESS . . . ' 'PROCESS  THE  REQUEST 
IF  OFFICE. STATUS-WORKING, 

NOW  INITIATE. TASK  GIVING  EXEC  AND  CLASS  GO  AHEAD 
OTHERWISE...  "FILE  THE  REQUEST  UNTIL  THE  BREAK  IS  OVER 
CREATE  A  TASK  ' 'TO  ACT  AS  A  MEMO 
LET  WHO-EXEC  "RECORD  WHO  THE  REQUEST  WAS  FOR 
LET  WHAT-CLASS  "RECORD  THE  TYPE  OF  TASK 
LET  DELAY. TYPE-0  ’ 'RECORD  THAT  THE  MEMO  REPRESENTS  A  REQUEST 
"RECEIVED  DL'EING  A  BREAK  PERIOD 
FILE  THE  TASK  IN  THE  REQUEST. FILE 
'AHEAD'  DESTROY  THE  REQUEST 

RjnURN  '  'TO  THE  TIMING  ROUTINE 
END 
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ROUTINE  TO  INITIATE .TASK  GIVEN  EXECUTIVE  AND  ClASS 
DEFINE  EXEC. TIME  AND  SEC.TIME  >S  REU  VARIABLES 
IF  EXECUTIVE,  "NO  EXECUTIVE  :  iS  SEEN  SPECIFIED,  SELECT  ONE 

FOR  each  EXECUl’IVE  WITH  ST.VTE-IDLE  AND  POSITION  GE  NEED(CLASS), 
FIND  THE  FIRST  CASS 
IF  FOUND,  GO  TO  'SEC .TEST’ 

ELSE...  "NO  EXECUTIVE  AVAILABLE  FOR  THIS  TASK 
'NO. EXEC'  LET  D-1  "INDICATING  THE  TASK  IS  WAITING  FOR  AN  EXECUTIVE 

'NO. WORKER'  CRFATE  A  TASK  LET  WHO-0  LET  WHAT-CLASS 

DELAY  .TYPE-D 

FILE  THE  TASK  IN  THE  REQUEST. FILE 
RETURN  "TO  THE  TIMING  ROUTINE 
ELSE...  "AN  EXECUTIVE  HAS  BEEN  REQUESTED 

IF  ST.\TE-i-IDLE, 

' 'REQUESTED  EXECUTIVE  IS  BUSY,  LOOK  FOR  SUBSTITUTE 
CALL  SUBSTITUTION  GIVING  EXECUTIVE  YIELDING  EXECUTIVE 
THEN  IF  EXECUTIVE-0,  ' 'NO  SUBSTITUTE  CAN  BE  FOUND 
GO  TO  NO. EXEC 

ELSE  ' 'AN  EXECUTIVE  IS  AVAILABLE,  IS  A  SECRETARY  REQUIRED? 

'SEC .TEST'  IF  CLASS  >-  SECRETARY. REQUIRED. CLASS, 

' 'A  SECRETARY  IS  REQUIRED  FOR  THIS  TASK 

PERFORM  SECRETARY. SELECTION  YIELDING  SECRETARY 

IF  SECRETARY-0,  ' 'NO  SECRETARY  IS  AVAILABLE  FOR  TASK 

LET  D-2  "INDICATING  THE  TASK  IS  WAITING  FOR  A  SECRETARY 
GO  TO  NO .WORKER 

ELSE...  "DETERMINE  TIME  EXECUTIVE  AND  SECRETARY  WORK 
LET  EXEC .TIME»EXPONENTIAL.F(TASK.TIME(CLASS) , 1) 

LET  SEC .TIME-EXEC .TIME  +  EXPONENTIAL. F(TASK . TIME(CLASS) , 1)* 

SKILL .FACTOR(SECRETARY, CLASS) 

LET  STATUS -WORKING  "SET  THE  SECRETARY  IN  THE  WORKING  STATE 
SCHEDULE  A  REVIEW  (^ECUTIVE,  SECRETARY)  IN  SEC.TIME  MINUTES 
REGARDLESS . . . 

IF  EXEC .TIME-0  "EXECUTIVE  IS  WORKING  ALONE  AND  MUST  COMPUTE 
'  'ms  TIME 

LET  EXEC. TIME-2*EXP(WENriAL.F (TASK .TIME (CLASS)  ,  1) 

REGARDLESS . . . 

LEI  STATE-WORKi:  G  "SET  THE  EXECUTIVE  IN  THE  WORKING  STATE 
SCHEDULE  AN  EXECUTIVE. AVAILABLE (EXECUTIVE)  IN  EXEC. TIME  MINUTES 
IF  CLASS  >  INDUCE. TYPE,  "CHECK  FOR  INDUCED  TASK 
CREATE  A  REQUEST  CALLED  INDUCED 
LET  EXEC (INDUCED) -EXECUTIVE 
LET  CLASS (INDUCEI^CLASS-1 

SCHEDULE  THE  REQUEST  CALLED  INDUCED  IN  UNIFORM.F(0 .0, 1 .0, 1)  HOURS 
REGARDLESS 

RETURN  "TO  THE  TIMING  ROUTINE 
END 
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■RETURN' 


ROUTINE  SUBSTITUTION  GIVEN  EXEC  YIELDING  EXECl 
' 'FIND  THE  FIRST  IDLE  EXECUTIVE  WITH  AT  LEAST  THT  SAME  RANK 
FOR  EACH  EXECUTIVE  WITH  STATE-IDLE  AND  POSITION  > 
POSITION(EXEC),  FIND  EXECl-THE  FIRST  EXECUTIVE 
IF  NONE,  LET  EXEC  1-0 

REGARDLESS  RETURN  ' 'TO  THE  CALLING  PROGRAM 
END 


ROUTINE  FOR  SECRETARY. SELECT ION  YIELDING  SECRETARY 
"FIND  THE  FIRST  IDLE  SECRETARY 

FOR  EACH  SECRETARY  WITH  STATUS-IDLE,  FIND  THE  FIRST  CASE 
IF  NONE,  LET  SECRETARY-0 

REGARDLESS  RETURN  ' 'TO  THE  CALLING  PROGRAM 
END 


EVENT  REVIEW  GIVEN  EXECUTIVE  AND  SECRETARY 
IF  STATE -t-IDLE,  "EXECUTIVE  BUSY,  CANNOT  REVIEW  JOB 
CREATE  A  TASK 

LET  WHO-EXECUTIVE  LET  WHAT-SECRETARY 

LET  DELAY.TYPE-3  "INDICATING  A  DELAYED  REVIEW 

FILE  THE  TASK  IN  THE  REQUEST. FILE 

DESTROY  THE  REVIEW 

GO  RETURN 

ELSE ..."  EXECUTIVE  REVIEWS  SECRETARY'S  WORK 
IF  RANDOM.? (2)  LE  SATISFACTORY, 

' 'TASK  HAS  BEEN  PERFORMED  SATISFACTORILY 
SCHEDULE  A  SECRETARY .AVAILABLE(SECRETARY)  NOW 
GO  RETURN 

ELSE...  "TASK  MUST  BE  CORRECTED 

RESCHEDULE  IrilS  REVIEW  IN  13  MINUTES 
RETURN  ' 'TO  THE  TIMING  ROUTINE 
END 
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EVE!fr  EXECUTIVE  .AVAILABLE  GIVEN  EXECUTIVE 

LET  STATE-IDLE  ' ’ PUT  EXECUTIVE  IN  THE  IDLE  STATE 

IF  OFFICE  .STATUS -»-WORKING, 

' 'A  BREAK  PERIOD  IS  IN  PROGRESS 

LET  STATE-BREAK  ' ' PUT  THE  EXECUTIVE  In  THE  BREAK  STATE 
RESCHEDULE  THIS  EXECUTIVE .AVAILABLE  AT  TRUNC.F(TIME.V)+1 
GO  RETURN 

OTHERWISE...  "EXECUTIVE  IS  FREE  TO  WORK  ON  BACKLOGGED  TASKS 
IF  REQUEST. FILE  IS  EMPTY,  GO  RETURN 
ELSE...' 'FIND  TASKS  NEEDING  EXECUTIVE  ATTENTION 
FOR  EACH  TASK  IN  THE  REQUEST.  FILE  WITH  DELAY  .TYPE -n -2 
FIND  THE  FIRST  CASE  "NOT  WAITING  FOR  A  SECRET ARi 
IF  NONE,  GO  RETURN  "NO  BACKLOGGED  EXECUTT’'"  JOBS 
ELSE ..."  EXAMPLE  TA.SK 

REMOVE  THE  TASK  FR(»1  THE  REQUEST  .FILE 
IF  DELAY  .TYPE-O  OR  DELAY  .TYPE-1 ,  "WAIT  IS  TO  START  A  NEW  TASK 
CREATE  A  REQUEST  SUBTRACT'  1  FRCH  SUH. REQUESTS 
SCHEDULE  THE  REQUEST(WKO,  WHAT)NOW 
GO  AHEAD 

ELSE  ' 'TASK  IS  A  SECRETARY  REVIEW,  THE  VARIABLE  "WHAT" 

"IS  USED  FOR  THE  SECRETARY  IDENTIFICATION 
SCHEDULE  A  REVIEW(W1»,  WHAT)NEXT 
'AHEAD'  DESTROY  THIS  TASK 
'RETURN'  RETURN  "TO  THE  TIMING  ROUTINE 
END 


EVENT  SECRETARY. AVAILABLE  GIVEN  SECRETARY 

LET  STATUS-IDLE  "PUT  SECRETARY  IN  THE  IDLE  STATE 

IF  OFFICE . STATUS  -•  -WORKING , 

"A  BREAK  PERIOD  IS  IN  PROGRESS 

LET  STATUS-BREAK  "PUT  THE  SECRETARY  IN  THE  BREAK  STATE 
SCHEDULE  THIS  SECRETARY. AVAILABLE  AT  TRUNC.F(TIME .V)+l 
GO  RETURN 

ELSE...  "SECRETARY  IS  FREE  TO  WORK  ON  BACKLOGGED  TASKS 
IF  THE  REQUEST. PILE  IS  EMPTY,  GO  RETURN 
ELSE...  "FIND  TASKS  NEEDING  SECRETARIAL  ATTENTION 
FOR  EACH  TASK  IN  THE  REQUEST .FILE  WITH  DELAY .TYPE-2, 

FIND  THE  FIRST  CASE 

IF  NONE,  GO  RETURN  ' 'NO  TASKS  WAITING  F(»l  A  SECRETARY 
ELSE... 

REMOVE  THE  TASK  FROM  THE  REQUEST. FILE 

CREATE  A  REQUEST  SUBTRACT  1  FRCM  SUM. REQUESTS 

SCHEDULE  THE  REQUEST (WHO,  WHAT)NOW 

DESTROY  THIS  TASK 

'RETURN'  RETURN  "TO  THE  TIMING  ROUTINE 
END 
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EVEOT  END.0F.SIMIU.AT1C:; 

NOH  REPORT 

FOR  I-l  TO  EVENTS. V.  * 'EMPTY  THE  EVENTS  LIST 
UNTIL  EV.S(I)  IS  EMPTY,  DO 

REMOVE  THE  FIRST  J  FROM  EV.S(I) 

GO  TO  REQ  OR  REV  OR  SEC  Ofe  EXEC  PER  I 
'REQ'  DESTROY  THE  REQUEST  CALLED  J 
GO  LOOP 

'REV  DESTROY  THE  REVIEW  CALLED  J 
GO  LOOP 

'SEC'  DESTROY  THE  SECRETARY. AVAILABLE  CALLED  J 
GO  LOOP 

'EXEC  DESTROY  THE  EXECUTIVE .AVAILABLE  CALLED  J 
'LOOP'  LOOP 

RETURN  "TO  THE  TIMING  ROUTINE 
END 


ROUTINE  FOR  OFFICE. STATUS 
DEFINE  T  AS  A  REAL  VARIABLE 
LET  T-M0D.F(TIME.V,24) 

IF  12  »  HOUR,F(TIME.V)  OR  10.75  <  T  <  11  OR 

15.75  <  T  <  16,  RETURN  WITH  0  "INDICATING  BREAK  IN  PROGRESS 
ELSE  RETURN  WITH  1  "INDICATING  OFFICE  NOW  WORKING 
END 


ROUTINE  REPORT 
START  NEW  PAGE 

PRINT  2  LINES  WITH  AVG. BACKLOG  AND  STD. BACKLOG  THUS 
AVERAGE  BACKLOG  IS  **.*★  TASKS 
STD. DEV  IS  *.** 

SKIP  3  OUTPUT  LINES 
BEGIN  REPORT 
BEGIN  HEADING 
PRINT  2  LINES  THUS 

ANALYSIS  OF  EXECUTIVE  STATUS 
IDLE  WORKING  BREAK 
END  "HEADING 

FOR  EACH  EXECUTIVE,  PRINT  1  LINE  WITH  STATE. EST ( EXECUTI VE, IV 
TIME.V,  ';'rATF,!’ST(i;xECUTTVE,2)/TIME.V,  STATE. EST (EXECUTIVE,  3)/ 
TIME.V  AS  FOLLOWS 

END  "REPORT 
SKIP  3  OUTPUT  LINES 
BEGIN  REPORT 
BEGIN  HEADING 
PRINT  2  LINES  THUS 

ANALYSIS  OF  SECRETARY  STATUS 
IDLE  WORKING  BREAK 
END  "HEADING 
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FOR  EACH  SECRETARY,  PRINT  I  LINE  WITH  STATUS .EST( SECRETARY, 1 ) / 

TIME.y,  STATUS. EST (SECRETARY, 2) /TIME. V,  STATUS .EST( SECRET ARY, 3) / 
TIME.V  AS  FOLLOWS 
*^** 

END  ' ’REPORT 
SKIP  5  OUTPUT  LINES 

PRINT  1  LINE  WITH  SUM. REQUESTS  AND  TIME.V  LIKE  THIS 
**i»pREQUESTS  WERE  PROCESSED  IN  *★**.*  SIMULATED  DAYS 
RETUW3  '  'TO  CALLING  PROGRAM 
END 
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Descrtptton  of  the  Program 

Rather  than  describe  the  SIMSCRIPT  II  program  In  detail,  we  dis¬ 
cuss  only  those  statements  that  highlight  SPL  features  mentioned  In 
previous  sections.  The  purpose  of  the  examples  Is  to  show  how  various 
languages  Implement  simulation  programming  concepts,  not  to  describe 
the  languages  themselves.  Those  who  wish  to  understand  the  examples 
and  the  languages  more  fully  can  do  so  by  studying  their  respective 
programming  manuals. 

The  preamble  to  the  subprograms  that  make  up  the  SIMSCRIPT  II 
model  declares  the  static  system  structure  of  the  model,  using  the 
entlty-attrlbute-set  organization  framework;  declares  the  events  that 
compose  the  d^^iamlc  structure;  defines  special  properties  of  the  t\ro 
structures,  such  as  the  mode  of  attributes,  the  ranking  of  sets,  and 
the  priority  order  of  events;  and  specifies  data-collectlon  and  analysis 
Casks.  The  preamble  Is  a  set  of  global  declarations  that  describe  the 
system  being  simulated  to  the  SIMSCRIPT  II  compiler.  In  the  case  of 
the  data-collectlon  and  analysis  statements  and  some  debugging  state¬ 
ments  not  illustrated  in  the  example,  the  preamble  also  specifies  tasks 
that  the  compiler  Is  to  perform. 

The  main  routine  provides  overall  simulation  experiment  control. 

It  calls  on  a  programmer-written  routine  to  initialize  the  static 
system  state  and  provide  events  for  the  timing  routine  that  will  set 
Che  model  In  motion.  The  START  SIMULATION  statement  removes  the  first 
scheduled  event  (the  initialized  event  with  the  earliest  event  time) 
from  the  file  of  scheduled  events  and  starts  the  simulation  by  trans¬ 
ferring  program  control  to  it. 

Eventually,  either  by  running  out  of  data  or  by  progrananer  action, 
all  events  are  processed,  no  new  ones  are  created,  and  control  passes 
from  the  timing  routine  (represented  by  the  START  SIMULATION  stateoient) 
to  the  statement  that  follows  It.  If  there  are  no  more  data,  the 
sequence  of  experiments  Is  terminated.  If  there  are  more  data,  the 
system  is  initialized  for  another  run. 

The  two  routines  MAIN  and  INITIALIZATION  illustrate  the  primary 
features  SIMSCRIPT  II  provides  for  controlling  simulation  experiments. 
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In  the  next  routine,  an  event  natned  REQUEST,  the  features  of 
interest  are  the  statements  CREATE,  FILE,  anJ  DESTROY.  The  CREATE 
statement  generates  a  new  entity  of  the  class  TASK  whenever  it  is 
executed;  this  statement  is  SIMSCRIFT  II 's  way  of  dynamically  allocating 
storage  to  system  entities  as  they  are  heeded.  The  DESTROY  statement 
takes  a  named  entity,  REQUEST  in  this  example,  and  returns  It  to  a 
pool  of  free  data  storage,  providing  space  for  the  subsequent  creation 
of  additional  entities.  The  FILE  statement  takes  a  named  entity  and 
puts  it  in  a  set  along  with  other  entities.  In  this  example  an  entity 
named  TASK  is  put  in  a  set  named  REQUEST .FILE . 

In  the  routine  INITIATE .TASK,  the  features  to  note  are  IF  and  FOR 
statements  that  perform  logical  tests  and  searches,  the  statistical 
function  EXP(n<ENTIAL.F,  and  the  event-scheduling  statements.  The  IF 
and  FOR  statements  are  SIMSCRIFT  II 's  way  of  dealing  with  the  common 
programming  problem  of  determining  the  state  of  objects,  or  of  the 
system  itself,  and  selecting  among  objects  according  to  stated  criteria. 
The  statistical  function  indicates  the  way  sampling  is  done  to  repre¬ 
sent  statistically  varying  phenomena.  The  last  argument  in  the 
EXPCRtENTIAL .F  function-call  selects  one  of  ten  built-in  number  streams; 
if  the  argument  is  negative  the  antithetic  variate  of  the  generated 
pseudorandom  number  is  used.  The  SCHEDULE  statements  are  the  basic 
mechanism  for  specifying  events  that  are  to  occur  in  the  future.  When 
a  SCHEDULE  statement  is  executed,  an  entity,  called  an  event  notice, 
of  a  specified  type  is  put  in  a  time-ordered  file  that  is  ordered  by 
Che  schedule  time;  when  the  simulation  clock  advances  to  this  time, 
the  event  is  executed  and  is  said  to  "occur." 

The  event  routines  EXECUTIVE .AVAILABLE  and  SECRETARY. AVAILABLE 
contain  REMOVE  statements.  These  statements  retrieve  entities  from 
sets  according  to  criteria  that  are  either  implied  or  specified  in 
the  preamble.  One  of  the  functions  of  the  preamble  is  to  specify  such 
things  as  the  relationship  that  entities  in  sets  have  to  one  another. 

The  REPORT  routine  illustrates  SIMSCRIFT  II 's  facilities  for 
generating  reports.  No  output  is  collected,  analysed,  or  printed 
automatically  by  SIMSCRIFT  II.  Rather,  the  data-collection  and  anal¬ 
ysis  statements  of  the  preamble  and  the  report  specification  features 
pictured  are  used  to  tailor  reports  to  simulation  experiment  requirements. 
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Natural  ly,  this  brief  explaaatlon  haa  not  made  the  program  clear 
in  all  its  details  —  that  was  not  its  intent.  Rather,  its  purpose  is 
to  show  how  SIMSCRIPT  11  provides  the  simulation-oriented  features  dis¬ 
cussed  in  Sec.  III.  All  three  of  the  following  examples  follow  this 
same  pattern. 

a 

SIMULA;  A  PROCESS-ORIENTED  LANGUAGE 

This  example  has  been  taken  from  Chapter  13  of  [l3].*  Its  model 
is  similar  to  those  used  in  many  SPL  descriptions,  and  aside  from 
terminology,  structurally  very  similar  to  the  SIMSCRIPT  II  model  just 
presented.  The  program  ie  quite  different. 

The  Model 

A  job  consists  of  machine  groups, >each  containing  a  given  number 
of  identical  machines  in  parallel.  The  system  is  described  from  a 
machine  point  of  view,  i.e.,  the  products  flowing  through  the  system 
are  represented  by  processes  that  are  passive  data  records.  The 
machinec  opetete  on  the  products  by  remote  accessing. 

The  products  consist  of  orders,  each  for  a  given  number  of  product 
units  of  the  same  type .  There  is  a  fixed  number  of  product  types.  For 

I 

each  type  there  is  a  unique  routing  and  given  processing  times. 

For  each  machine  group  (number  mg)  there  is  a  set  availfmgl  of 
idle  machines  and  a  set  quermgl.  which  is  a  product  queue  common  to 
the  machines  in  this  group.  The  products  are  processed  one  batch  at 
a  time.  A  batch  consists  of  a  given  number  of  units,  which  must  belong 
to  the  same  order.  The  batch  sire  depends  on  the  product  type  and  the 
machine  group. 

A  product  queue  is  regarded  as  a  queue  of  orders .  The  queue  dis¬ 
cipline  is  essentially  first-ln-flrst-out,  the  position  of  an  order  in 
the  queue  being  defined  by  the  arrival  of  the  first  unit  of  that  order. 
However,  if  there  is  less  than  an  acceptable  batch  of  units  of  a  given 
order  waiting  in  the  queue,  i.e.,  if  the  batch  size  is  too  small  as 
yet,  the  next  order  is  tried.  The  last  units  of  an  order  are  accepted 

* 

Courtesy  of  the  Norwegian  Computing  Canter. 
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as  a  batch,  even  if  the  number  of  units  is  less  than  the  ordinary 
minimum  batch  size.  If  a  machine  finds  no  acceptable  batch  in  the 
product  queue,  it  waits  until  more  units  arrive. 

Although  the  individual  pieces  of  product  are  "units,"  a  unit  is 
not  treated  as  an  individual  item  in  the  present  model.  For  a  given 
order  and  a  given  step,  i.e.,  machine  group,  in  its  schedule,  we  define 
an  opart  (order  part)  record  to  represent  the  group  of  units  currently 
involved  in  that  step.  The  units  are  cither  in  processing  or  waiting 
to  be  processed  at  the  corresponding  machine  group. 

An  order  is  represented  by  a  collection  of  opart  records.  The 
sum  of  units  in  each  opart  is  equal  to  the  number  of  units  in  the 
order.  Each  opart  is  a  member  of  a  product  queue.  If  a  machine  group 
occurs  more  than  once  in  the  schedule  of  a  product  type,  there  may  be 
more  than  one  opart  of  the  same  order  in  the  product  queue  of  that 
machine  group. 

Among  the  attributes  of  an  opart  record  are  the  following  integers 
the  order  number,  ono .  the  product  type,  the  step,  the  number  of  units 
waiting,  rm,  and  the  number  of  units  in  processing,  The  flow  of 

units  in  the  system  is  effected  by  counting  up  and  down  the  attributes 
nw  and  np  of  opart  records. 

An  opart  record  is  generated  at  the  time  when  the  first  batch  of 
units  of  an  order  arrive  at  a  machine  group.  It  is  entered  at  the  end 
of  the  corresi>ondlng  product  queue.  The  opart  will  remain  a  member  of 
this  queue  until  the  last  unit  has  entered  processing.  It  will  drop 
out  of  the  system  when  the  last  unit  has  finished  processing.  A 
Boolean  attribute  last  is  needed  to  specify  whether  a  given  opart  con¬ 
tains  the  last  units  of  the  order  involved  in  this  step. 

At  a  given  time  the  units  of  an  order  may  be  distributed  or  sev¬ 
eral  machine  groups.  There  will  be  an  opart  record*  for  each  of  them. 

★ 

An  opart  process  will  reference  the  one  at  the  next  step,  i.e., 
machine  group,  through  an  element  attribute  "successor."  An  order  is 
thus  represented  by  a  simple  chain  of  opart  records.  The  one  at  the 


The  terms  "record"  and  "process"  both  refer  to  the  data  structure 
associated  with  a  particular  group  of  units.  See  Lines  5-7,  p.  66. 
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head  has  no  successor,  the  one  at  the  tail  has  its  attribute  "last" 
equal  to  t  rue .  The  chain  "moves"  through  the  system  by  growing  new 
heads  and  dt opping  off  tails. 


Fig.  9  --  Flow  of  products  through  the  shop 


Figuie  9  shows  tliree  consecutive  steps  in  the  schedule  of  prodijcts 
of  a  given  type.  A  product  queue  consists  of  oparts  (circles)  connected 
by  vertical  lines.  Oparts  belonging  to  the  same  order  are  connected  by 
horizontal  lines.  Machines  are  represented  by  squares.  .\  dotted  line 
between  an  opart  and  a  machine  indicates  a  batch  of  units  in  processing. 
When  the  batch  of  the  third  opart  in  que[j]  is  finished,  a  new  opart 
receiving  this  batch  will  be  generated  and  included  in  que[k]. 

The  Program 


The  following  program  fiagment  is  part  of  ihe  head  of  a  SIMUIA 
block  describing  the  above  system.  A  machine  activity  is  given.  For 
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clarlty,  only  statementa  essential  for  the  behavior  of  the  model  are 
shovm.  The  program  is  not  complete.  Underlined  words  are  SIMULA 
keywords . 


1  . 
2  . 

3. 

4. 

5. 
6  . 
7  . 
a . 
9  . 

lO. 
11  . 
12  . 

13. 

14. 
13. 
16. 

17. 

18. 

15. 
20. 
21 . 
22  . 

23. 

24. 

25. 

26. 

27. 

28. 

29. 

30. 


se t  array  que ,  avail  [l:nmg];  integer  U; 

integer  procedu  re  nextm  (type ,  step) ;  integer  type ,  step  ..... ; 
tea  I  procedure  ptime  (type,  step) ;  integer  type,  step; . . .  . ; 
integer  procedure  bslte  ( type ,  mg) ;  Integer  type ,  mg ; .... ; 
activity  opart  (ono,  type,  step,  nw,  np,  last,  successor); 
integer  ono,  type,  step,  nw,  np; 

Boolean  last;  e lement  successor; 
act ivlt  y  machine  (mg);  integer  mg; 

btgi'n  Integer  batch,  next;  Boo  lean  B;  element  X; 
serve;  X:“head  (qiie[mg]); 

for  X:«suc  (X)  whi le  exist  (X)  do 

Inspect  X  when  opart  do 

begin  batch  :«bsi*e  (type,  rag); 

^  nw  <  batch  then  begin 

i f  last  then  batch  :«nw  else  go  to  no  end ; 
nw  :»nw  -  batch;  np  :»np  +  batch; 
i f  lastAnw  -  0  then  remove  (X); 
activate  first  (avallLmg]); 

hold  (batch  x  ptime  (type,  step)xuntform  (0.9,  1.1,  U)); 
np  :■  np  -  batch;  B  ;■  lastAnw  +  np  •  0; 
next  :»  nextm  (type,  step); 
inspect  successor  when  opart  do 

begin  nw  :•  nw  +  batch;  last  :•  B  end 
otherotae  begin  successor  :■ 

new  opart  (ono,  type,  step  +  1,  batch,  0,  B,  none) : 
include  (successor,  que  [ne..t])  end; 
activate  first  (avail  [next]); 
go  to  serve; 
no  ;  end : 

wait  (avail  [mg]);  remove  (current);  go  to  serve  end; 


Line  1  The  sets  contain  oparts  and  idle  machines,  respectively. 

The  variable  U  defines  a  pseudorandom  number  stream 
(line  19K 

Lines  2-4  The  functions  "nextm"  and  "ptlme"  specify  the  next 

machine  group  and  the  current  processing  time  for  a 
given  product  type  and  step  in  the  schedule,  "baize" 
determines  the  batch  size,  given  the  product  type  and 
machine  group  number.  The  three  lunctions  are  left 
unspecified,  i.e.,  their  programs  are  not  shown. 

Lines  5-7  The  meanings  of  the  attributes  of  opart  processes  have 

been  explained  in  the  model  description.  The  activity 
★ 

body  is  a  dummy  statement:  an  opart  process  is  a  data 
record  with  no  associated  actions. 

Line  8  The  machine  activity  extends  to  and  includes  line  30. 

The  parameter  oig  is  the  machine  group  number.  Machines 
belonging  to  the  same  group  are  completely  similar. 

Line  9  "batch"  is  the  size  of  the  current  batch  of  units, 

"next"  is  the  number  ot  the  next  machine  group  for  the 
units  currently  being  processed,  the  meaning  of  "B"  is 
explained  below  (line  20),  and  "X"  Is  used  fur  scanning. 

Line  10  Prepare  for  scanning  the  appropriate  product  queue. 

Select  the  first  opart  In  que[mg] . 

Line  11  Scan.  The  controlled  statement  is  Itself  a  connection 

statement  (lines  12*29). 

★ 

In  the  SIMULA  nomenclature,  a  process  is  a  dynamic  structure  oi 
an  activity,  i.e.,  an  activity  is  a  process  prototype. 

★  ★ 

"Connection  it  a  (peans  oi  acceaaing  local  variables  from  out- 
aide  the  block  in  which  they  are  defined.  In  this  instance,  attributes 
of  the  oparts  stored  in  queuing]  are  being  referenced. 
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Llne  12  There  is  only  one  connecLion  branch  (lines  12-29). 

Since  a  product  queue  contains  only  opart  records, 
connection  must  become  effective.  The  attributes  of 
the  connected  opart  are  accessible  inside  the  connec¬ 
tion  block. 


Line  13  Compute  the  standard  batch  size. 

Lines  14,  13  A  smaller  batch  accepted  only  if  the  opart  is  at  the 
tail  end  of  the  chain.  In  this  case  "nw"  is  nonzero 
(ci.  line  17),  and  the  units  are  the  last  ones  of  the 
order.  Otherwise  the  next  r.paii  is  tried  by  branching 
to  the  end  of  the  set  inspection  loop. 

Line  16  "batch"  units  are  transferred  from  the  waiting  state 

to  the  in-processing  stare  b>  reducing  nw  and  Increasing 
np. 


Line  17 


The  opart  is  removed  from  the  product  queue  when  pro¬ 
cessing  has  started  on  the  last  units  of  the  order. 


Line  18  The  current  machine  has  found  an  acceptable  batch  of 

units,  and  has  updated  the  product  queue.  There  may 
be  enough  units  left  for  another  bat-h;  therefore  the 
next  available  machine  in  this  group  (mg)  is  activated. 
If  there  is  no  idle  machine,  the  set  availfag]  la  empty 
and  the  statement  has  no  effect  .  See  also  lines  27 
and  30 . 


Line  19  The  expecteu  processing  time  is  proportional  to  the 

number  of  units  In  the  batch.  The  actual  proceaalng 
time  is  uniformly  distributed  in  the  Interval  +  lOX 
around  the  expected  value.  The  sequence  of  pseudo¬ 
random  drawings  Is  determined  by  the  initial  value  of 
the  variable  U. 

Line  20  Processing  la  finished;  np  is  reduced.  The  Boolean 

variable  B  gets  the  value  true  If  and  only  If  the  laat 
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unii.8  ot  an  order  have  now  bet-.n  processed.  In  that 
case  the  connected  opart  should  drop  off  the  chain  at 
this  system  time  (see  coiwnents  to  line  28).  It  follows 
that  B  Is  always  the  correct  (next)  value  of  the  attrib¬ 
ute  "last"  of  the  succeediitg  opart  tllnes  23,  25). 

Compute  the  number  of  the  machine  group  to  receive  the 
current  batch  of  units. 

The  element  attribute  "successor"  is  Inspected.  The 
connection  statement,  lines  22-26,  has  two  branchea. 

This  is  a  connection  block,  executed  if  "successor" 
refers  co  an  opart.  The  latter  is  a  member  of  the 
product  queue  of  the  next  machine  group.  It  receives 
the  processed  batch  of  units,  wliich  are  entered  in  the 
waiting  state.  The  attribute  "la?t"  is  updated.  Notice 
that  the  attributes  referenced  in  this  inner  connection 
block  are  those  belonging  to  the  successor  to  the  opart 
connected  outside  (K)  . 

Lines  24.  25  If  the  connected  opart  (X)  is  at  the  head  of  the  chair, 
Che  value  of  "successor"  Is  assumed  equal  to  none .  and 
otbe rwlse  branch  Is  taken.  A  new  opart  is  generated, 
and  a  reference  to  It  Is  stored  in  "successor,"  The 
new  opart  has  the  same  "ono"  and  "type"  as  the  old  one, 
and  Its  "step"  Is  one  greater.  It  has  "batch"  units 
In  the  waiting  state  and  none  in  processing.  Its 
attribute  "last"  Is  equal  to  "B" .  Since  the  new  opart 
has  become  the  head  of  the  chain.  Its  "successor" 
should  be  equal  to  none .  Notice  that  the  Initial 
value  of  "last"  may  well  be  t rue .  e.g.,  if  the  order 
contains  a  single  unit. 

Line  26  The  new  opart  is  Included  at  the  end  of  the  product 

queue  of  the  next  machine  group. 


Line  2  1 


Line  22 


Line  23 
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Llne  27  The  current  machine  has  now  transferred  a  batch  of 

units  to  the  product  queue  of  next  machine  group. 
Tl^erefore  the  first  available  machine  (If  any)  of  that 
group  is  activated.  If  that  machine  finds  an  accept¬ 
able  batch,  it  will  activate  the  next  machine  in  the 
same  group  (line  lb).  This  takes  care  of  the  case  in 
which  the  batch  transferred  is  larger  than  the  standard 
batch  size  of  the  next  machine  group  for  this  type  of 
product  . 

Line  28  The  machine  immediately  returns  to  the  beginning  of 

its  operation  rule  to  look  for  another  acceptable  batch, 
starting  at  the  front  end  of  the  product  queue.  At 
this  point,  if  B  is  true .  the  connected  opart  is  empty 
of  units  and  will  not  be  referenced  any  more.  We  can 
regard  it  as  having  dropped  off  the  chain.  It  is  easy 
to  demonstrate,  however,  that  the  opart  will  physically 
leave  the  system,  i.e.,  that  its  reference  count  is 
reduced  to  zero.  The  possible  stored  references  are; 

(1)  The  variable  X  and  the  connection  pointer  "opart" 
of  this  machine  or  another  one  of  the  same  group.  The 
go  to  statement  leads  out  of  the  connection  block, 
which  deletes  the  connection  pointer.  X  is  given 
another  value  in  line  10.  Any  other  machine  referencing 
this  opart  would  have  to  be  suspended  in  line  19,  which 
Is  impossible  since  np  is  zero  (cf.  the  second  state¬ 
ment  of  line  16) . 

;2)  Set  membership  in  queLmg].  The  opart  must  have 
been  removed  from  the  queue  (by  this  machine  or  another 
one)  since  "last"  Is  true  and  nw  is  now  zero  (line  17). 
(3)  The  attribute  "successor"  of  the  opart  preceding 
this  one  in  the  chain.  The  first  opart  of  this  order 
to  enter  the  systems  has  no  predecessor.  Provided 
that  this  first  one  drops  out  when  1-  is  empty,  our 
conclusion  follows  by  induction  (see  below). 
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I.lne  29  Tli«  end  of  the  connection  block  and  of  the  statement 

controlled  by  the  for  clause  In  line  11. 

Line  30  If,  after  having  searched  the  entire  product  queue, 

the  machine  has  feuno  no  acceptable  batch,  ft  Includes 
f^self  in  the  appropriate  "avail"  set  and  goes  passive. 
Its  local  sequence  control  remains  within  the  watt 
statement  as  long  aa  the  machine  is  in  the  passive 
state.  When  the  machine  is  eventually  activated  (by 
anothci  machine:  line  27  or  18),  1  removes  Itself 
frotn  the  "avail"  set  and  returns  to  scan  the  product 
queue.  The  "avail"  sets  aic  operated  in  the  ffrst-ln- 
first-out  fashici. 

The  mechanism  for  feeding  orders  Into  the  system  Is  not  shown 
above.  This  Is  typically  done  by  the  Main  Program  or  by  one  or  more 
"arrival"  processes,  which  generate  a  pattern  of  orders,  either  spec¬ 
ified  in  detail  by  Input  data,  or  by  random  drawing  according  to  given 
relative  average  frequencies  of  product  types  and  order  sites. 

An  arrival  pattern  defined  completely  "at  random*  Is  likely  to 
cause  severely  fluctuating  product  queues,  if  the  loan  on  the  system 
is  near  the  maximum.  The  following  is  a  simple  way  of  rearranging 
the  input  pattern  so  as  to  achieve  a  more  uniform  load.  The  algorithm 
is  particularly  effective  if  there  are  different  "bottle-necks"  for 
the  different  types  of  products. 

31.  activity  arrival  (type,  mgl,  pt); 

32.  integer  type,  mgl;  real  pt; 

33.  begin  integer  units; 

34.  loop:  select  (units,  type);  Id  id  +  1; 

35.  include  (new  opart  (id,  type,  1,  units,  0,  true. 

none),  que[mgl]); 

activate  first  (avail  [mgl]); 
hold  (ptxunits) ;  go  to  loop  end ; 
rocedure  select  (n,  type);  velue  type;  integer  n,  type;  .  .  .; 


36. 

37. 

38. 


linin'.  "'I 


72- 


t.  ine  31 


Line  34 


Line  33 


Line  36 


There  will  be  one  "arrival"  process  tor  each  product 
type,  "ragi"  Is  the  number  of  the  first  machine  group 
in  the  schedule  o£  this  type  of  product.  "pt"  Is  a 
stipulated  "average  processing  time"  per  unit,  chosen 
8u  as  to  obtain  a  wanted  average  througliput  of  units 
of  this  type  (see  line  37). 

The  procedure  "select"  should  choose  the  size,  "units," 
of  the  next  order  of  the  given  type,  e.g.,  by  random 
drawing  oi  by  searching  a  given  arrival  pattern  for 
the  next  order  of  this  type.  "Id"  is  a  nonlocal  integer 
variable  used  for  numbering  the  orders  consecutively. 

An  order  Is  entered  by  generating  an  opart  record  that 
contains  all  the  units  of  the  order.  The  units  are 
initially  In  the  waiting  state.  The  order  is  filed 
into  the  appropriate  product  queue.  The  set  member¬ 
ship  Is  the  only  reference  to  the  opart  stored  by  the 
arrival  process.  Conseque^ntly,  this  opart  will  leave 
the  system  when  it  becomes  empty  of  units,  as  assumed 
earlier  (line  28) . 

A  machine  in  the  appropriate  group  is  notified  of  the 
arrival  of  an  older. 


Line  37  The  next  order  of  the  same  type  is  scheduled  to  aiiive 

after  a  waiting  time  proportional  to  the  size  of  this 
order,  which  ensures  a  uniform  load  of  units  (of  each 
type)  . 


The  "output"  of  units  from  the  system  can  conveniently  be  arranged 
by  routing  all  products  to  a  dumny  machine  group  at  the  end  of  the 
schedule.  It  contains  one  or  more  "terminal  machines"  (not  shown  here). 


In  SIMULA,  process  records  that  are  no  longer  needed,  i.e.,  are 
not.  referenced  by  any  other  process,  are  automatical '  y  returned  to 
available  storage.  This  contrasts  with  the  DESTROY  statem.nt  used  by 
SIMSCRIPT  for  the  same  task. 
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whlch  may  perform  observational  functions  such  as  recording  the  com¬ 
pletion  of  orders. 

The  dynamic  setup  of  the  system  is  a  separate  task,  since  ini¬ 
tially  the  Main  Program  is  the  only  process  ^present .  The  Main  Program 
should  generate  (and  activate)  all  processes  that  are  "permanent"  parts 
of  the  system,  such  as  machines,  arrival  processes,  and  observational 
processes.  The  system  can  be  started  empty  of  products.  However,  a 
"steady"  state  can  be  reached  in  a  shorter  time  if  orders  (opart 
records)  are  generated  and  distributed  over  the  product  queues  in 
suitable  quantities. 

Experimental  results  are  obtained  by  observing  and  reporting  the 
behavior  of  the  system.  Three  different  classes  of  outputs  can  be 
distinguished : 

(1)  On-line  reporting.  Quantities  describing  the  current  state 
of  the  system  can  be  printed  out,  e.g.,  with  regular  system 
time  intervals:  lengths  of  product  queues  in  terms  of  units 
waiting,  the  total  number  of  units  in  the  system,  the  number 
of  idle  machines  in  each  group,  etc.  A  more  detailed  on¬ 
line  reporting  may  be  required  for  program  debugging. 

(2)  Accumulated  machine  statistics.  By  observing  the  system 
over  an  extended  period  of  system  time,  averages,  extrema, 
histograms,  etc.,  can  be  formed.  Quantities  observed  can 
be  queue  lengths,  idle  tiroes,  throughputs,  and  so  on.  The 
accumulation  of  data  could  be  performed  by  the  machine 
processes  themselves. 

Example .  To  accumulate  frequency  histogram  of  the  idle 
periods  of  different  lengths  for  individual  machines.  Insert 
the  following  statements  on  either  side  of  the  "wait"  state¬ 
ment  of  line  30: 

"tidle  :■  time"  and  "histo(T,  H,  time  -  tidle,  1),"  where 
"tidle"  is  a  local  real  variable,  and  T  and  H  are  arrays. 

T[i]  are  real  numbers  that  partition  observed  idle  periods 
(time  -  tidle)  into  classes  according  to  their  lengths,  and 
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H[i]  are  integers  equal  to  the  number  of  occurrences  in 
each  class.  The  system  procedure  "hlsto”  will  Increase  H[i] 
by  one  (the  last  parameter),  where  i  is  the  smallest  integer 
such  that  T[l]  is  greater  than  or  equal  to  the  idle  period, 
"time  -  tidle."  T  and  H  together  thus  define  a  frequency 
histogram,  where  T[il  -  T[i  -  1]  is  the  width  of  the  i'th 
columr.,  and  H[i]  is  the  column  length. 

(3)  Accumulated  order  statistics.  During  the  lifetime  of  an 
opart  record,  the  "history"  of  an  order  at  a  given  machine 
group  can  be  accumulated  and  recorded  in  attributes  of  the 
opart.  The  following  are  examples  of  data  that  can  be  found. 

The  arrival  of  the  first  unit  of  the  order  at  this  machine  group 
Is  equal  to  the  time  at  which  the  opart  is  generated.  The  departure 
time  of  the  last  unit  is  equal  to  the  time  at  which  the  variable  B 
gets  the  value  true  (line  20  of  a  machine  connecting  the  opart). 

The  sum  of  waiting  times  for  every  unit  of  the  order  in  this  queue 
is  equal  to  ch*;  integral  with  respect  to  system  time  of  the  quantity 
nw  (which  is  a  step  function  of  time).  The  integral  can  be  computed 
by  the  system  procedure  "accum."  The  statements  "nw  :•  nw  +  batch" 
(lines  16  and  23)  are  replaced  by  "accum  (anw,  tnw,  nw,  +  batch)," 
where  the  real  variables  anw  and  tnw  are  additional  attributes  of  the 
opart  process,  with  initial  values  zero  and  "time,"  respectively.  The 
procedure  will  update  nw  and  accumulate  the  integral  in  anw.  It  is 
equivalent  to  the  statements:  anw  anw  -f  nw  x  (time  -  tnw); 
tnw  :•  time;  nw  ■  nw  +  batch. 

It  is  worth  noticing  that  arrival  times,  waiting  times,  etc., 
cannot  in  general  be  found  for  individual  units,  unless  the  units  are 
treated  as  individuals  in  the  program.  Neither  can  the  maximum  waiting 
time  for  units  in  an  order.  The  average  waiting  time,  however,  is 
equal  to  the  above  time  integral  divided  by  the  number  of  units  in 
the  order. 

The  complete  history  of  an  order  in  the  shop  is  the  collection 
of  data  recorded  in  the  different  oparts  of  the  order.  These  data 
can  be  written  out  on  an  external  storage  medium  at  the  end  of  the 
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llfetlme  of  each  opart.  That  is,  an  output  record  could  be  written 
out  before  line  23,  whenever  B  is  true .  containing  Items  such  as  the 
order  number,  ono,  the  sum  of  waiting  times,  anw,  the  current  system 
time,  etc.  When  the  simulation  has  been  completed,  the  data  records 
can  be  read  back  in,  sorted  according  to  order  numbers,  and  processed 
to  obtain  information  concerning  the  complete  order,  such  as  the  total 
transit  time,  total  waiting  time,  etc. 

The  same  information  can  be  obtained  by  retaining  the  complete 
opart  chain  in  the  system  until  the  order  is  out  of  the  shop;  however, 
th; s  requires  more  memory  space.  The  chain  can  be  retained  by  making 
the  arrival  process  include  the  Initial  opart  in  an  auxiliary  set,  or 
by  having  a  pointer  from  the  opart  currently  at  the  head  of  the  chain 
back  to  the  initial  one.  The  opart  chain  can  be  processed  by  the  ter¬ 
minal  machine.  (The  order  is  completely  through  the  shop  at  the  time 
when  the  attribute  "last"  of  the  opart  in  the  terminal  product  queue 
gets  the  value  true.)  In  the  former  case  the  terminal  machine  should 
also  remove  the  appropriate  opart  from  the  auxiliary  set,  in  order  to 
get  rid  of  the  opart  chain. 

CSL;  AN  ACTIVITY- ORIENTED  LANGUAGE 

* 

This  example  has  been  taken  from  [U]-  While  unlike  the  two 
previous  models,  it  is  indicative  of  the  kinds  of  models  industrial 
firms  construct  to  solve  practical  operating  problems. 

The  Model 

This  example  is  a  simulation  of  the  operation  of  a  simple  port, 
which  consists  of  an  outer  deep-water  harbor  and  a  series  of  berths. 
Each  berth  can  hold  one  large  ship,  which  can  berth  only  at  full  tide, 
or  three  small  ships,  which  can  also  move  at  half- tide.  The  tide  runs 
in  a  12-hour  sequence,  out  for  seven  hours,  half- tide  for  an  hour. 

A  distribution  of  unloading  times  for  large  ships  is  available 
as  data,  and  unloading  times  for  small  ships  are  normally  distributed. 
Interarrival  times  are  negative  exponentially  distributed. 

★ 

Courtesy  of  the  IBM  United  Kingdom  Data  Centre. 
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The  program  is  to  record  Che  waiting  tiroes  of  large  and  small 
ships  and  the  times  for  which  the  berths  are  empty.  The  purpose  of 
the  simulation  might  be  to  study  the  operation  as  a  basis  for  exper¬ 
iments  to  find  a  more  efficient  way  of  scheduling  Che  wrking  of  the 
port,  or  Co  determine  the  effect  of  providing  extra  berths.  The 
scheduling  used  in  this  model  is  a  simple  flrsC-in  first-out  scheme. 


nono  o  oonn  nnoo  oon 
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The  Program 


PORT  SIMULATION  EXAMPLE  PROGRAM 


CONTROL 

CLASS  TIME  SHIP. 100  BERTH. 4 
C  DEFINE  CLASSES  OF  100  SHIPS  AND  4  BERTHS 

SET  OCEAN  HARBOUR  LARGE  SMALL  FREE  PART  FULL 
SET  SHIPIN( BERTH) 

DEFINE  THE  SETS  REQUIRED,  INCLUDING  AN  ARRAY  OF  AS 
MANY  SET"  .\3  THERE  ARE  BERTHS,  SHIPLN(X)  WILL  HOLD 
A  LIST  Oi  THE  NAMES  OF  SHIPS  IN  BERTH  X 
NAME  S  B 

INTEGER  TIDE  TLARGE  TSMALL 
TIME  CHANGE  ARRIVE  FINISH 

DEFLNE  TWO  NAME  VARIABLES,  AN  INTEGER  VARIABLE  TO 
SHOW  THE  STATE  OF  THE  TIDE,  AND  ADDITIONAL  TIME 
CELLS.  ALSO  TWO  INTEGERS  TO  HOLD  TOTAL  ARRIVALS 
OF  LARGE  AND  SMALL  SHIPS  RESPECTIVEF.Y . 

HIST  LARGEQ  25,2,5  SMALLQ  25,2,5  IDLE  25,2,5 
HIST  UNLOD  20,3,5 

DEFINE  THE  HISTOGRAMS  REQUIRED.  LARGEQ  HAS  25 
CELLS  WITH  RANGE  0-4  (MIDPOINT  ?.)  .  5-9,10-14  ETC. 
UNLOD  WILL  CONTAIN  TtiE  UNLOADING  TIME  DISTRIBUTION 
FUR  LARGE  SHIPS. 

IN  in. 

ACTIVITIES 

TIDES  ARRVL  BTIL  BTHS  DBTH  ENDING 

SPECIFY  THE  LIST  OF  SECTORS  (ACTIVITIES) 

END 


SECTOR  INT.TL 
T. FINISH-240 00 
T. CHANGE-7 
T.ARRIVE-0 
TIDE-0 

THIS  SECTOR  IS  ENTEP.ED  ONLY  ONCE  AND  SETS  UP  THE 
INITIAL  STATE  OF  THE  MODEL.  T. FINISH  REFERS  TO  THE 
TIME  AT  WHICH  SIMULATION  IS  TO  FINISH,  T. CHANGE  TO 
THE  TIME  AT  WHICH  THE  TIDE  NLXT  CHANGES  AND  TIDE 
C  SHOWS  l-HI  STATE  OF  THE  TIDE  AS  FOLLOWS  - 

C  0  TIDE  OUT  1  HALF  IN  2  TIDE  FULL  3  HALF  IN 

C  T. ARRIVAL  SHOWS  THE  TIME  BEFORE  THE  NEXT  ARRIVAL  OF 

C  A  SHIP  AT  THE  PORT. 

FOR  X  =.  l.SHIP 

SHIP.X  INTO  OCEAN 
FOR  X  -  1, BERTH 
BERTH  .X  INTO  FREE 
T. BERTH .X-O 


. .  .  ,  . aKaffi 
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C  INITIALLY  ALL  SHIPS  ARE  IN  OCEAN 

C  AND  ALL  BERTHS  FREE 

READ  (5,10)  UNLOD 

C  READ  IN  THE  DISTRIBUTION  GIVEN  AS  DATA. 

10  FORMAT  (lA) 

END 


SECTOR  TIDES 

C  THIS  SECTOR  IS  CONCERNED  WITH  TIDE  CHANGES 

r. CHANGE  EQ  0 

C  WHICH  CAN  ONLY  OCCUR  WHEN  THEY  ARE  DUE 

TIDE+1 

GOTO  (10,20,10,30)  TIDE 

C  CHANGE  TIDE  MARKER  AND  RESET  TIME  CELL  FOR  NEXT 

C  CHANGE 

10  T. CHANGE- 1 

GOTO  60 

20  T.CHANCE-3 

GOTO  60 

30  T. CHANGE-7 

TIDE-0 
60  DUMMY 

C  AND  RETURN  TO  CONTROL  SEGMENT 

END 


SECTOR  ARRVT, 

C  THIS  SECTOR  IS  CONCERNED  WITH  ARRIVALS  OF  SHIPS 

14  T. ARRIVE  EQ  C 

C  WHICH  CAN  ONLY  OCCUR  WHEN  ONE  IS  DUE 

FIND  S  OCEAN  FIRST  6il3 
S  FROM  OCEAN  INTO  HARBOUR 
T.S=0 

C  FIND  THE  FIRST  SHI?  IN  THE  OCEAN  MOVE  IT  TO  THE 

C  HARBOUR  AND  ZERO  ITS  TIME  CELL 

T.ARRIVE-NEGEXP(7) 

C  SAMPLE  THE  TIME  TO  THE  NEXT  ARRIVAL 

UN IFORM(SY STEMS TP£AM)  GT  0.75  &13 
S  INTO  LARGE 
TLARGE+1 
GOTO  14 

13  S  INTO  SMALL 

TSMALL+1 
GOTO  14 

C  A  QUARTER  OF  THE  SHIPS  ARE  LARGE,  OTHERS  SMALL. 

C  GO  BACK  TO  START  OF  SECTOR  IN  CASE  NEGEXP  HAS 

C  GIVEN  /  ZERO  SAMPLE 

15  WP.ITE(6,100)  T, FINISH, CLOCK 

100  LINGEN 


no  on  no  no  non  no  onnno 
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1  NOT  ENOUGH  SHIPS  IN  MODEL  -  SIMUIJVTION  TERMINATED 

2  TIME  LEFT  TIME  ELAPSED  ***** 

T. FINISH  -  0 

C  IF  A  SHIP  IS  NOT  FOUND  IN  OCEAN,  WRITE  MESSAGE 
C  AND  SET  T. FINISH  SO  THAT  SIMULATION  CEASES  IN 
C  SECTOR  ENDNG. 

GOTO  ENDNG. 

END 


SECTOR  BTHL 

C  THIS  SECTOR  IS  CONCERNED  WITH  BERTHING  LARGE  SHIPS 

TIDE  EQ  2 
FIND  B  FREE  ANY 
FIND  S  HARBOUR  FIRST 
S  IN  LARGE 

C  THE  TIDE  MUST  BE  FULL,  THERE  MUST  BE  A  FREE  BERTH 

C  AND  A  large  SHIP  WAITING  IN  THE  HARBOUR 

ENTER  -T.S,LARGEQ 

WHEN  THE  SHIP  ENTERED  THE  HARBOUR  ITS  TIME  CELL 
WAS  SET  TO  ZERO.  SINCE  THEN  IT  HAS  BEEN  REDUCED 
AT  EACH  TIME  ADVANCE  AND  SO  -T.S  IS  THE  WAITING¬ 
TIME  OF  THE  SHIP.  THIS  IS  RECORDED  IN  THE 
HISTOGRAM 

B  FROM  FREE  INTO  FULL 
S  FROM  HARBOUR  INTO  SHI  PIN (B) 

THE  BERTH  IS  NOW  FULL  AND  THE  SHIP  MOVES  FROM  THE 
HARBOUR  INTO  THE  BERTH 
ENTER  -T.B,IDLE 

JUST  AS  -T.S  SHOWED  THE  SHIPS  WAITING  TIME  SO  -T.B 
SHOWS  THE  BERTH  IDLE  TIME 
T.S-SAMPLE(UNI,OD) 

SAMPI-E  an  UNLOADING  TIME  FOR  THE  SHIP 
RECYCLE 

CAUSE  ANOTHER  PASS  THROUGH  THE  SECTORS  (BECAUSE 
MORE  THAN  ONE  SHIP  MIGHT  BERTH  AT  THE  SAME  TIME) 

END 


SECTOR  ETHS 

THIS  SECTOR  IS  CONCERNED  WITH  BERTHING  SMA.LL  SHIPS 
AND  IS  SIMILAR  TO  THE  PREVIOUS  ONE 
TIDE  GE  1 

FIND  S  HARBOUR  FIRST 
S  IN  SMALL 

FIND  B  PART  ANY  620 

THE  SHIP  IS  MOVED  TO  A  PARTLY  FULL  BERTH  IF  THERE 
IS  ONE 

SHIPIN(B)  EQ  2  630 

B  FROM  PART  INTO  FULL 

IF  THE  BERTH  AiilEADY  HAS  TWO  SHIPS  IN  IT,  IT  NOW 
BECOMES  FULL 
GOTO  30 
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20  FIND  B  FREE  ANY 

B  FROM  FREE  INTO  PART 

C  IF  NO  PARTLY  FULL  BERTH  WAS  FOUND,  SEEK  A  FREE 

C  BERTH  WHICH  NOW  BECOMES  PARTLY  FULL 

ENTER  -l.B.IDLE 
C  RECORD  IDLE  TIME 

30  ENTER  -T.S.SMALLQ 

T.S-DEVIATE(5. 0,20.0) 

S  FROM  HARBOUR  INTO  SHIPIN(B) 

RECYCLE 

C  AS  IN  BFRTHING  OF  LARGE  SHIPS 

END 


SECTOR  DBTH 

C  THIS  SECTOR  IS  CONCERNED  WITH  DEBERTHING 

TIDE  NE  0 

C  THE  TIDE  CANNOT  BE  OUT 

FOR  X  -  1, BERTH 

C  DEAL  WITH  EACH  BERTH  SEPARATELY  IN  TURN 

20  FOR  S  SHIPIN(X)  FIRST  &15 

T.S  LE  0 
CHAIN 

S  IN  SMALL 
OR  S  IN  LARGE 
TIDE  EQ  2 
DUMMY* 

C  FIND  A  SHIP  IN  THE  BERTH  WHICH  IS  READY  TO  LEAVE 

C  (TIME  CELL  HAS  BEEN  REDUCED  TO  ZERO  OR  BEYOND  BY 

C  TIME  ADVANCE)  AND  WHICH  CAN  DO  SO  AT  THE  PRESENT 

C  STATE  OF  THE  TIDE.  IF  N(WE  -  GO  ON  TO  TRY  THE 

C  NEXT  BERTH 

RECYCLE 

C  SET  RECYCLE  SWITCH  TO  TRY  SECTORS  AGAIN  BEFORE 

C  TIKE  ADVANCE  (IN  PARTICULAR  BERTHING  SECTORS 

C  MAY  NOW  SUCCEED) 

S  FROM  SHIPIN(X)  INTO  OCEAN 
S  IN  LARGE  616 
S  FROM  LARGE 
T. berth, X«0 

BERTH. X  FROM  FULL  INTO  FREE 
GOTO  15 

C  IF  SHIP  LEAVING  IS  LARGE  BERTH  IS  NOW  FREE. 

C  ZERO  ITS  TIME  CELL  SO  THAT  IDLE  TIME  CAN  BE 

C  COMPUTED  LATER.  THEN  GO  TO  NEXT  BERTH. 

16  S  FROM  SMALL 

SHIPIN(X)  EQ  0  &17 

BERTH. X  FROM  P.ART  INT' .  -E 

TO. BERTH. X-0 
GOTO  15 


Dr 


DUMMY  is  a  scatcment  that  does  nothing  vhen  executed. 


OU'-'  OOtJO"-* 
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SmiLARLY  IF  SHIP  LEAVING  IS  SMALL  AND  NOW  THERE 
ARE  NONE  LEFT  IN  THE  BERTH. 

SHIPIN(X)  EQ  2  6i20 

BERTH .X  FROM  FULL  INTO  PART 
GOTO  20 

IF  SMALL  SHIP  IS  LIAVING  AND  BERTH  WAS  PREVIOUSLY 
FULL,  RECORD  FACT  THAT  IT  IS  NOW  ONLY  PARTLY  FULL 
IN  EITHER  CASE  GO  BACK  TO  SEE  IF  ANY  MORE  SHIPS 
ARE  READY  TO  LEAVE  THIS  SAME  BERTH 

DUMMY 

DUMMY 

END 


SECTOR  ENDNG 

THIS  SECTOR  IS  CONCERNED  WITH  OUTPUT  OF  RESULTS 
T. FINISH  EQ  0 

WHICH  IS  TO  BE  DONE  AFTER  TIME  HAS  BEEN  ADVANCED 
SO  THAT  T. FINISH  HAS  BECOME  ZERO 
WRITE(6 ,100) 

100  LINGEN  SKIP  PAGE 

1  PORT  SIMULATION  RESULTS 
WRITE(6 ,101) 

101  LINGEN  SKIP  2 

1  TOTAL  LARGE  SMALL 

WRirE( 6 , 102)  (TLARGE+TSMALL) .TLARGE .TSMALL 

102  LINGEN  SKIP  1 

1  *****  *****  *****  SHIPS  ENTERED  HARBOUR 

FOR  S  HARBOUR 
S  IN  LARGE  &10 
J+1 

10  DUlWY 

K-HARBCOR-J 

WRITE  (6, 10  3)  (J+K)  ,J,K 

103  LINGEN  SKIP  1 

1  *****  *****  *****  SHIPS  LEFT  IN  HARBOUR 

L-LARGE-J 
H-SHALL-K 

WRITE(6,104)(L-m)  ,L,M 

104  LINGEN  SKIP  1 

1  *****  *****  *****  SHIPS  STILL  IN  BERTHS 

TLARGE-J 
TSMALL-K 

C  CALCULATE  NUMBERS  OP  SHIPS  THAT  HAVE  LEFT  HARBOUR 

WRITE(6,100) 

WRITE(6,200) 

200  LINGEN  SKIP  2 

1  CELL  RANGE  LARGEQ 
YH) 

J-0 
K-0 


SMALLQ  IDLETIME 


o  o  o  o  o 
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FOR  X-1 ,2) 

WRITE(6,300)  Y,(1f+4)  ,URGEQ(X)  ,SMALLQ(X)  ,Ii)UE(X) 
Y+5 

J+LARGEQ(X) 

K+SMALLQ(X) 

DU>«Y 

LONCL-TLXRGE  -  J 
LOHGS-TSMALL-K 

TLARGE  NOW  HAS  TOTAL  NUMBER  OF  U^RCE  SHIPS  WHICH 
HAVE  LEFT  THE  HARBOUR.  J  HOLDS  THE  TOTAL  NUMBER 
OF  ENTRIES  IN  THE  HISTOGRAM.  THEREFORE  TLARGE  -  J 
IS  THE  NUMBER  OF  SHIPS  WHOSE  WAITING  TIMES  WERE 
OUTSIDE  THE  RAtXiE  OF  THE  HISTOGRAM 
WRITE(6.«)0)  LONGL, LONGS 
STOP 

300  LINCEN  SKIP  1 

X  ***  XO  ***  *  *  IHrtriHe  iHMrM 

400  LINGEN  SKIP  1 

1  OVER  *****  ***** 

END 
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Descrtptlon  of  the  ProRram 

The  counenc*  embedded  In  the  program  document  its  micro  behavior 
rather  well.  What  is  not  obvious  from  the  program  is  its  macro 
behavior,  i.e.,  how  activities  are  controlled,  initiated,  and  performed. 

The  CONTROL  segment  of  the  program  has  four  tasks:  it  defines 
global  variables,  it  defines  functions,  it  defines  global  FORMAT  and 
LINGEN  statements,  and  it  specifies  activities  through  the  sector  list. 
Of  these,  only  the  last  is  Important  to  us  now.  Note  that  the  CONTROL 
segment  of  CSL  is  similar  to  the  SIMSCRIFT  II  preamble. 

A  short  discussion  of  how  time  is  represented  within  CSL  models 
and  how  simulation  is  carried  out  should  clarify  the  operations  of 
the  program. 

Interactions  in  a  real  system  are  dependent  on  time  and  the  system 
moves  through  time.  It  Is  therefore  nccessarv  to  have  some  means  of 
representing  time  in  a  siraulacion  program.  Time  values  are  held  in 
variables  called  T-cells.  T>cellt  may  arise  in  two  ways;  they  are 
either  defined  as  integer  cells  or  arrays,  or  as  cells  attached  to 
their  names  with  "T".  For  example,  if  the  class  of  ships  is  defined 
thus : 

CLASS  TIME  SHIP. 100 

then  this  serves  to  define  entity  names  as  above,  and  also  100  T-cells 

addressed  as  T.SHIP.l .  T.SHIP.IOO.  An  array  of  integer  T-cells 

could  be  defined  as 

TTwy.  BREAKDOWNS  (10) 

T-cells  have  all  the  propertlea  of  other  integer  cells  and  may  par¬ 
ticipate  normally  in  arithmetic  and  tests.  Their  time-advancing 
properties  are  additional. 

Time  advancement  is  performed  in  a  repeated  two-atage  process 
as  follows.  Stage  1  scans  all  T-cells  to  find  the  sraalleat  positive 
nonzero  value  in  any  cell  .  This  Is  regarded  as  the  time  of  the  next 
event,  or  the  time  at  «i'hich  an  event  is  next  able  to  arise  In  the 
system.  The  program  is  now  advanced  to  this  position  in  time  by  sub¬ 
tracting  this  value  from  all  T-cells.  This  completes  stage  1. 
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In  stage  2  the  program  Itself  Is  entered.  The  user  mast  specify 
his  program  as  a  aeries  of  Individual  routines  called  activities,  and 
phase  2  consists  of  an  attempt  to  obey  each  of  the  activities  In  turn. 
Each  activity  describes  the  rules  relating  to  the  performance  of  one 
kind  of  activity  In  the  system;  for  example,  that  of  unberthtng  a  ship. 

The  program  statements  In  an  activity  normally  begin  with  a  series 
of  tests  to  find  out  whether  the  activity  can  be  Initiated;  these  may 
be  tests  on  T-cells  to  see  whether,  for  Instance,  any  ships  are  due  to 
leave  a  berth.  Following  the  opening  tests  are  the  statements  that 
actually  carry  out  the  work  of  the  activity,  e.g.,  arithmetic  and  set- 
manipulation  statements. 

The  actual  question  of  division  of  the  program  Into  activities 
Is  governed  by  Individual  programming  style.  The  activities  must 
clearly  cover  all  possible  courses  of  action  available  in  the  system, 
but  this  is  not  the  whole  story.  For  Instance,  in  the  example  program 
the  berthings  of  large  and  small  ships  arc  handled  as  separate  activ¬ 
ities.  The  orders  In  these  are  largely  duplicate;  should  they  there¬ 
fore  be  combined  In  one?  This  Is  purely  a  question  of  taste  and  as 
such  Is  unresolvable  on  logical  grounds. 

The  structure  of  a  CSL  test  can  now  be  more  fully  explained.  The 
most  frequent  use  of  a  test  Is  at  the  start  of  an  activity;  under 
these  circuiBStanceB ,  If  the  test  falls.  It  may  be  assumed  that  the 
activity  cannot  be  carried  out. 

For  this  reason,  the  customary  operation  of  computer  test  orders 
has  been  changed;  a  teat  failure  leads  to  transfer  of  control,  usually 
to  the  next  activity,  whereas  in  the  esse  of  success  the  next  state¬ 
ment  Is  obeyed.  To  provide  laore  detailed  control  of  flow  a  ttsteoMnt 
label  may  be  specified;  e.g., 

DATA  (10)  Si  ^  &  87- 

♦ 

In  event  of  failure,  control  goes  to  the  statemmnt  labeled  87. 

The  second  phase.  It  will  be  noticed,  consists  of  an  sttsmpt  to 
obey  all  the  activities  specified  In  the  system.  Apparently,  this 
Involves  much  redundant  effort,  as  at  moat  points  in  time  one  or  two 
sctlvltlsa  only  are  likely  to  be  entered  successfully  and  the  rest 


*An  &  before  a  number  indicates  Chat  it  Is  s  statement  label. 
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will  be  abandoned  after  a  test  or  two;  but  s  closer  analysis  shows 
that  computing  time  to  carry  out  work  of  this  kind  must  be  expended 
in  any  simulation  prugramming  system,  whether  it  is  carried  out  under 
direct  control  of  the  programmer  or  not.  It  seems,  therefore,  most 
useful  to  make  the  necessary  testing  explicit  and  under  the  user's 
control  . 

When  all  the  activities  have  been  entered,  the  normal  procedure 
la  that  a  return  to  phase  1  takes  place  and  time  is  further  advanced. 

This  procedure  is  not  in  itself  sufficient;  activities  are  interlinked 
and  the  completion  of  or.f  activity  may  enable  the  initiation  of  another. 
For  example,  the  unberthlng  of  one  ship  will  free  a  berth  that  another 
may  use.  The  user  can  control  this  In  two  ways:  first,  by  careful 
choice  of  the  order  in  which  activities  are  specified,  and  second,  by 
the  use  of  a  special  recycling  device  to  cause  further  attempts  to 
obey  the  activities  to  be  made. 

SPSS/ 360:  A  TRANSACTIOK- FLOW  LANGUAGE 

A  Simple  harbor  model  Is  used  to  illustrate  GPSS .  While  not 
identical  to  the  CSL  model,  the  match  is  close  enough  to  provide  some 
feel  for  how  the  languages  represent  similar  systems.  The  example  is 
taken  from  [24] . 

The  Model 

Ships  arrive  at  a  small  port  with  a  known  arrival  pattern.  While 
in  port,  the  ships  unload  some  of  their  cargo,  taking  a  certain  amount 
of  time,  and  then  proceed  on  their  voyages.  There  being  only  one  pier, 
a  ship  must  wait  if  It  arrives  while  another  is  unloading.  If  aevcral 
ships  are  waiting,  the  one  that  arrived  first  will  be  unloaded  first. 

Of  interest  here  is  the  total  amount  of  time  a  ship  will  spend  in  port, 
including  the  time  spent  waiting  for  the  pisi  to  become  available. 

ir 

Reprinted  by  permission  from  (H20-0304-1  General  Purpose  Slosila- 
tion  System/360  Introductory  User's  Hanual),  @  (1967),  and  (H20-0186-1 
General  Purpose  Simulation  SysLsm/360  Application  Description),  @  (1966), 
by  Intemattonsl  Business  Machlt.cs  Corporation. 


The  groat  behavior  of  the  syatem  can  be  pictured  quite  tinply  at: 


Arrival 


Waiting 


Seiee  Facility 
Hold  for  Procett 
Releate 


Statittica 


Shipa  arrive  at  harbor  in 
specified  arrival  pattern. 
Average  time  between 
artivalt  la  32  hours. 


If  pier  it  free,  dock  ahip. 
If  pier  la  busy,  join  the 
line  of  waiting  shl’'t. 


Begin  to  unload  cargo. 
Unloading  time  la  25  +  23 
hours.  When  finished, 
ship  leavea  pier . 


Record  time  ahip  apent 
in  harbor. 


Leave  System 


Ship  leaves  harbor. 


The  Program 

Unlike  moat  SPI<S,  GPSS  has  two  representations,  a  flowchart  and 
a  coding  form  language.  The  flowchart  model  of  the  simple  harbor 
system  is  shown  in  Fig.  lO. 

The  coding  form,  or  statement  language  model,  is  shown  in  Fig. 
11.  There  ia  a  direct  correspondence  between  its  stateiaenta  and  the 
flowchart  symbols  of  Fig.  10. 
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Cenerate  Lranaactlons  (ships)  a(.  an 
average  rale  of  one  every  32  time  units 
(hours)  . 


Queue  up  transaction  (ship)  in  queue  !• 
If  facility  I  (pier)  Is  busy. 


Sciee  facility  l(pier)  If  it  is  free  or, 
when  it  becomes  free,  make  it  busy. 


Depart  from  queue  1,  since  transaction 
(ship)  Is  no  longer  waiting  for  facility 
1  (pier) . 


Advance  time  while  this  transaction  is 
delayed  (ship  unloaded)  for  25  +  2C  time 
units  (hours) . 


Release  facility  1  (pier),  making  it  free. 


Tabulate  in  Table  10  the  total  time  spent 
by  transaction  (time  ship  was  in  harbor). 


Terminate  transaction  (ship  leaves  harbor) . 


Fig.  10  •-  GPSS  flowchart  for  the  simple  harbor  system 


Fig.  11.  --  GPSS  Harbor  Model 
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Descrlptlon  of  the  Program 

The  dynamic  enclcles  in  GPSS  are  called  "transactions."  These 
represent  the  units  of  traffic,  such  as  ships  in  this  example.  They 
a..e  "created"  and  "destroyed"  as  required  during  the  simulation  run, 
and  can  be  thought  of  as  moving  through  the  system  causing  actions  to 
occur.  Associated  with  each  transaction  are  a  number  of  parameters, 
to  which  the  user  can  assign  values  to  represent  characteristics  of 
the  transaction.  For  example,  a  transaction  representing  a  ship  might 
carry  the  aa»unt  of  cargo  it  Is  to  unload  in  a  parameter.  This  number 
could  then  be  used  in  the  simulator  logic  to  determine  how  long  the 
unloading  operation  would  take.  Transactions  can  Le  related  to  one 
another  by  placing  them  in  groups  that  can  be  searched,  scanned,  and 
modified . 

Entitles  of  the  second  class  represent  elements  of  system  equip 
ment  that  are  acted  upon  by  transactions.  These  include  facilities, 
stores,  and  logic  switches.  A  facility  can  handle  only  one  transaction 
at  a  time,  and  could  represent  the  pier  In  the  example  given.  It 
represents  a  potential  bottleneck,  A  score  can  handle  several  trans¬ 
actions  concurrently,  and  could  be  used  to  represent  a  parking  lot  or 
a  typing  pool.  A  logic  switch  is  a  two-stote  indicator  that  can  be  set 
by  one  transaction  to  modify  Che  flow  of  other  transactions.  It  could 
model  a  traffic  light  or  the  "next  window"  sign  of  a  bank  teller. 

In  order  to  measure  system  behavior,  two  types  of  statistical 
entities  are  defined;  queues  and  tables.  Each  queue  maintains  a 
list  of  transactions  delayed  at  one  or  more  points  in  the  system, 
and  keeps  a  record  of  the  average  number  of  transactions  delayed  and 
the  length  of  these  delays.  A  Cable  may  be  used  to  collect  any  sort 
of  frequency  distribution  desired.  These  two  entitles  provide  a 
major  portion  of  the  GPSS  output. 

The  operational  entitles,  called  "blocks,"  constit  te  the  fourth 
and  final  class.  Like  the  blocks  of  a  diagram,  they  provide  the  logic 
of  a  system,  instructing  the  transactions  where  to  go  and  what  to  do 
next.  Tliese  blocks,  in  conjunction  with  the  other  three  classes  of 
entities  identified  above,  constitute  the  language  of  GPSS. 
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To  provide  input  for  the  simulation,  control  and  definition  cards 
are  prepared  from  a  flowchart  of  the  system.  This  constitutes  the 
model  in  GPSS  language.  Once  the  system  model  is  loaded,  the  GPSS 
program  generates  and  moves  transactions  from  block  to  block  according 
to  timing  information  and  logical  rules  incorporated  in  the  blocks 
themselves.  Each  movement  is  designated  to  occur  at  suae  partlculdi 
point  in  time.  The  program  automatically  maintains  a  record  of  these 
times,  and  executes  the  movements  in  their  correct  time  sequence. 

When  actions  cannot  be  performed  at  the  originally  scheduled  time  -- 
for  example,  when  a  required  facility  is  alreadv  in  use  --  processing 
tempoiari ly  ceases  for  that  transaction.  The  program  automatically 
maintains  a  status  of  the  condition  causing  the  delay,  and  as  soon  as 
it  changes,  the  transaction  is  activated  again. 


SUMMARY 

Four  different  SPLs  have  been  presented  to  give  the  reader  a 
helpful  glance  at  different  concepts,  features,  and  language  styles  in 
use  today.  Except  for  SIMULA,  the  examples  Illustrate  the  latest 
releases  of  the  languages.*  SIMULA  67  has  been  discussed  in  public 
[l6],  but  since  no  written  material  was  available  at  the  time  this 
Memoranduo:  was  written,  an  example  of  it  is  not  included. 

As  these  examples  are  small  and  simple,  they  do  not  illustrate 
all,  or  even  necessarily  the  best,  features  of  all  four  languages. 

Some  languages  fare  better  than  others  in  these  short  destinations. 

The  reader  should  bear  in  mind  that  the  author's  intent  has  not  been 
language  Instruction,  but  a  broad-based  review.  No  language  selections 
should  be  based  on  the  details  of  this  section  alone.  Still,  It  will 
be  a  useful  exercise  for  the  reader  to  look  back  and  see  how  the 
different  languages  handle  elmllar  operations  such  as  time  control, 
entity  generation,  random  sampling,  and  set  manipulation. 


it  To  be  fair,  it  must  be  stated  that  of  the  foui  exaiq>les  presented, 

the  one  describing  CPSS/360  is  Che  least  representative  of  the  power  of 
I  its  full  language.  The  coogtlete  GPSS/360  language  contains  lA  entity  and 

I  I  A3  block  types. 


J 
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V.  CURRENT  SPL  RESEARCH 

SPL  research  le  currently  going  on  In  nonprofit  corporationt , 
unlveraltiea,  research  organizations  of  computer  manufacturers  and 
computer  software  companies,  industrial  research  organizations,  and 
aome  military  staff  groups.  With  only  a  little  airoplificati on,  one 
say  that  this  research  falls  in  eitner  of  two  general  categories: 
the  development  of  new  simulation  concepts,  and  the  development  of 
improved  simulation  ayatems.  The  two  are  quite  different,  yet,  since 
all  SPL  projects  seem  to  combine  some  elements  of  each,  few  people 
feel  they  are  doing  strictly  one  or  the  other.  Researchers  developing 
new  concepts  make  advances  in  operating  systems;  experimenters  devel¬ 
oping  new  operating  systems  find  new  concepts  arising  from  their  work. 
While  few  projects  can  qualify  as  either  pure  concept  development  or 
pure  operating  system  design,  this  distinction  is  made  in  the  following 
discussion . 

RESEARCH  ON  SIMULATION  CONCEPTS 

The  1967  IFIPS  Working  Conference  on  Simulation  Languages  [8] 
produced  several  Important  papers  on  SPL  design.  Several  of  theae 
described  modifications  to  existing  languages,  others  deacribed  new 
Languages  bated  on  refinements  of  existing  concepts.  The  spirit  of 
the  conference,  however,  was  evolution  rather  than  revolution. 

Despite  the  fact  that  many  SPLe  are  in  use  today,  there  have  only 
been  a  few  instances  in  which  a  language  introduced  concepts  aignif- 
tcantly  different  from  its  predecessors.  The  languages  beat  known  tor 
introducing  new  almuUtton  concepts  are:  GSP,  GPSS,  SIMSCRIPT,  SOL, 
SIMULA,  and  SIMPAC . 

So  far  aa  we  know,  no  completely  new  simulation  concepts  are 
being  developed  today.  Moat  language  research  la  aimed  at  unifying 
existing  language  concepts  (NSS  [50]  la  an  integration  of  SIMSCRIPT 
and  SIMULA  with  some  original  ideas  added  ),  extending  an  accepted 

★ 

IFIPS  is  the  IntemsCLonsI  Federstion  of  Information  Proccisins 
Societies , 

★★ 

The  n»8t  notable  of  these  is  a  sophisticated  version  of  the 
WAIT  UNTIL  conroand  of  SOL. 
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language  (SIMSCRIPT  II  extends  SIMSCRIPT  as  SIMULA  67  extends  SIMULA), 
or  writing  a  compiler  fur  an  existing  language  in  a  widely  used  pro¬ 
cedural  prograitinlng  language  (SPL  [32]  is  being  written  in  PL/I  and 
Is  derived  from  SIMULA  and  SOL).  A  good  deal  of  work  being  done 
throughout  the  prograoming  cooBnunlty  on  data-base  concepts  is  finding 
its  way  into  simulation  languages  (e.g.,  SIMULA  67  and  SIMSCRIPT  II) 
and  general-purpose  progracoming  languages  (reference  variable  exten¬ 
sions  to  PL/I  and  ALGOL  68).  Many  concepts  exploited  in  SPLs  for  some 
time  are  at  present  being  Integrated  into  COBOL. 

There  will  always  be  room  for  this  kind  of  research.  Programciing 
being  what  it  is,  it  has  no  theoretical  limit  and  there  will  always  be 
opportunities  for  improvetoenCs,  refinements,  and  extensions.  Until  a 
standard  simulation  programming  language  evolves,  if  that  day  ever 
Comes,  people  will  be  rewriting  SPLs  in  new  languages,  discovering 
new  ways  to  do  old  things  better,  and  making  evolutionary  changes  in 
concepts  and  Implementations. 

A  fertile  field  for  SPL  research  is  language  concepts.  One  area 
in  particular  that  has  hardly  been  touched  is  the  integration  of 
discrete-event  and  continuous-time  simulation.  Today,  continuous- 
time  eimuletion  it  conducted  on  both  analog  and  digital  computers, 
with  a  trend  toward  Incrcaaed  use  on  digital  and  hybrid  machines  [6]. 

The  languages  used  for  aioulatlng  continuous  systems  on  digital  com¬ 
puters  differ  greatly  from  the  SPLs  we  have  been  discussing.  There 
is  almost  no  relationship  between  discrete-event  and  continuous-time 
SPLs.  This  is  a  sad  and  hopefully  short-term  condition  that  will  be 
alleviated  when  more  research  effort  is  expended  on  language  integration. 

A  second  promising  area  is  the  synthesis  of  modell’ig  languages  with 
procedures  for  performing  statistical  experiments  and  analyzing  their 
results.  While  some  work  has  been  published  on  efficient  statistical 
analysis  and  experimentation  technique;  [20],  [49],  no  simulation  pro- 
granmlng  languages  presently  contain  such  procedures.  In  part,  this 
is  because  little  research  has  been  done  on  identifying  and  developing 
statistical  procedures  adapted  especially  to  simulation  studies.  As 
this  area  receives  more  attention,  however,  both  from  researchers  and 
practitioners,  language  designers  will  begin  to  consider  experimentation 


and  analyses  as  well  as  modeling  and  true  "simulation  systems"  will  be 
developed.  Statisticians,  language  designers,  simulation  analysts  and 
computer  programmers  will  contribute  jointly  to  such  efforts. 

To  speak  of  evolution  in  simulation  concepts  and  attempt  to  pre¬ 
dict  the  future  from  the  past,  one  can  be  guided  by  these  facts: 

Activity-  and  event-oriented  SPLs  emerged  at  roughly  the  same 
time.  GSP,  CSL,  GPSS,  and  SIMSCRIPT  were  developed  more  or  less  in 
parallel. 

Process -oriented  SPLs  came  later.  SOL  and  SIMULA  evolved  from 
the  above  languages  and  ALGOL. 

Current  research  is  attempting  to  unify  and  extend  the  activity-, 
event-,  and  process-orientations  [8]. 

l.nterest  In  the  statistical  analyses  and  interpretation  of 
simulation  results  seems  to  be  growing  more  rapidly  each  year. 

It  seeoa  a  good  bet  that  research  in  siiaulation  modeling  concepts 
will  continue  for  some  time.  A  great  many  modeling  techniques  still 
seem  forced  and  artificial;  there  is  much  room  for  improvensent  in 
progransing  techniques.  Topics  that  are  well  identified  as  needing 
research  attention  are:  decision  specification  --  decision  tables 
have  not  been  used  in  SPLs;  siisul taneity  —  parallel  interactlona  are 
currently  difficult  to  account  for;  synchronous  snd  asynchronous  behav 
ior  specification  --  richer  vocabularies  for  synchronising  system 
processes  and  for  executing  activities  asynchronously  are  required; 
data-base  definition  --  we  are  still  fsr  from  being  able  to  specify 
complex  state  descriptions  simply  and  elegantly;  data-base  management 
efficient  ways  of  partitioning  data  bases  end  unifying  them  without 
complication  remain  to  be  worked  out.  For  some  solutions  Co  these 
problems,  see  [4],  [15],  and  [47]. 

research  oh  operating  systehs  and  mechawisms 

As  slnaalation  is  an  experioiental  technique,  people  arc  always 
interested  In  msking  eimulatlon  programs  easier  to  use.  The  standard 
way  of  performing  a  simulation  experiment  today  is  to  sake  a  aeries 
of  experimental  runs  at  different  system  paremetcr  settings  by 


. . . . 
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submltting  a  set.  of  programs  and  data  decks  for  batch  processing.  While 
this  procedure  does  the  Job,  It  has  several  serious  defects;  1)  pro¬ 
gram  development  and  debugging  is  alow  and  painful;  2)  more  program 
runs  than  necessary  are  usually  made  because  of  the  rigidity  of  a  scheme 
requiring  that  a  program  be  run  completely  before  any  information  about 
its  behavior  can  be  obtained  and  used;  and  3)  it  Is  difficult  to  get  a 
feel  for  system  dynamics  by  looking  at  a  sequence  of  after-the-fact 
system  state  snapaliots.  Systems  are  being  designed  today  that  assist 
in  each  of  these  areas.  These  systems  use  interactive  languages,  time¬ 
sharing,  and  graphics . 

Interactive  Languages 

The  beat-knovm  interactive  SPL  is  OPS-3  [27].  This  language  was 
designed  and  Implemented  at  M.I.T.  and  used  successfully  to  demonstrate 
Che  feasibility  cf  interactive  modeling.  Operating  in  a  time-shared 
environment  under  the  M.I.T,  Compatible  Time  Sharing  System  (CTSS), 

OPS-3  provides  a  user  with  on-line,  interactive  comnunlcation  between 
himself  snd  a  programiing  system.  Using  it,  one  can,  in  a  single 
sitting,  compose  a  program,  test  and  modify  it,  expand  and  embellish 
it,  and  prepare  it  for  subsequent  production  use.  That  interactive 
languages  will  becoote  standard  in  Che  future  la  a  fact  eaCabllsheu  by 

it 

OPS-3,  JOSS,  BASIC,  RUSH,  and  other  Interactive  languages.  Greenberger 
and  Jones  [28]  have  specified  in  great  detail  the  features  of  an  ele¬ 
gant  interactive  simulation  system. 

Time-sharing  is  not  mandatory  for  Interactive  man-machine  dialogue, 
as  the  above  discussion  might  imply.  At  M.I.T.,  an  SPL  named  SIMPLE  is 
being  designed  and  programmed  to  operate  on  aii  IBM  1130  computer  [l7]. 

Or  such  a  small  machine,  it  is  economically  feasible  to  allow  one  person 
to  have  full  use,  even  Chough  the  computer  Is  inactive  a  great  deal  of 
the  time.  Time-sharing  allows  multiple  users  to  fully  utilize  a  com¬ 
puter,  but  it  is  not  necessary  for  an  interactive  language. 

In  the  future,  widely  used  SPLs.  will  undoubtedly  have  two  modes 
of  operation.  They  will  be  able  to  be  used  interactively  to  build 


JOSS  Is  the  trademark  and  service  mark  of  The  RAflD  Corporation 
for  its  computer  program  and  services  using  that  program. 
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modela;  for  this  «>lther  incremenCal  compilation  or  interpretation  will 
be  used.  They  will  also  be  capable  of  efficient  code  generation  througn 
optlmleing  compilation.  Thia  ia  necesaary  if  large  aimulation  atudiea 
requiring  lengthy  experimental  runa  are  to  be  made  economically. 

T imc-Sharing 

Tirae-aharing  entera  into  airaulation  in  that  it  makes  certain  things 
possible,  such  aa  Interactive  modeling.  During  model  construction  and 
testing,  when  programmer-program  interaction  is  important,  time-sharing 
makes  interaction  economical.  Time-sharing  can  also  be  useful  during 
model  utilization,  when  production  runs  are  made.  When  it  is  necessary 
to  study  a  model's  behavior,  rather  than  run  it  merely  to  derive  steady- 
state  statistics,  tiate-aharing  can  offer  substantial  benefits;  when  a 
man  can  enter  a  program  from  a  console,  watch  its  performance,  and  either 
leave  it  alone,  atop  it  permanently,  or  stop  it  temporarily  to  adjust 
some  parameters  and  start  again,  a  new  plateau  in  the  use  of  simulation 
will  be  reached.  It  will  then  become  possible  for  man  to  enter  into 
the  exploratory  and  experimental  process  more  completely  and  more  effi¬ 
ciently  than  he  can  in  today's  batch  environment.  For  this  reason, 
substantial  future  research  will  be  devoted  to  this  area.  The  SIMPLE 
language  mentioned  above  ia,  in  fact,  designed  to  do  thia.  IBM's  con¬ 
tinuous-time  simulation  language,  CSMP,  operates  in  this  mode  today 

Graphics 

A  considerable  amount  of  sinulation-oriented  graphics  research  is 
going  on  right  now,  Ac  the  Noruen  Division  of  United  Aircraft,  an  IBM 
2230  is  used  to  modify  source  language  GPSS  programs  and  view  their 
output  in  graphical  form  [54].  At  The  RAND  Corporation,  the  Grail  sys¬ 
tem  and  the  RAND  Tablet  are  used  to  construct  GPSS  programs  on-line 
from  hand-drawn  flowcharts  [30],  At  M.I.T.,  the  SIMPLE  project  is 
using  graphics  for  ooan-computer  interaction  during  modeling  and  exper¬ 
imentation.  Papers  have  been  written  on  the  use  of  graphics  in  simu¬ 
lation  modeling  and  the  use  of  existing  graphics  packages  for  analyzing 
simulation-generated  output  [44] . 
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There  is  little  vJoubt  that  Interactive  modeling  is  carried  out 
bettor  with  a  CRT  device  than  with  a  typewriter  or  line  printer.  When 
designing  programs,  flowcharts  and  other  symbolic  notation  can  be  dis¬ 
played.  For  analyzing  performance  data,  graphs  provide  more  insight 
than  do  lists  of  numbers.  The  growing  use  of  line-printer  plotting 
simulators  testifies  to  the  utility  of  graphic  output. 

Research  in  SPL  graphics  will  take  several  directions  in  the 
future.  Graphical  input  is  an  area  of  great  Interest  that  Is  Just 
getting  started.  Graphical  output  is  on  a  far  firmer  footing  and  has 
had  some  operational  success.  The  difficult  thing  about  incorporating 
graphics  in  an  SPL  is  its  ultimate  dependence  on  graphic  hardware  and 
software  that  are  not  properly  part  of  a  simulation  language.  State¬ 
ments  in  SPLs  that  perform  graphical  tasks  will,  for  a  long  time,  be 
computer-system  dependent,  and  not  independent  concepts.  Graphical 
research  will  also  prosper  for  interactive  modeling  and  program  modi¬ 
fication.  The  successes  and  benefits  claimed  to  date  virtually  insure 
this. 
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VI.  THE  FUTURE  OF  SPLS 

The  preceding  section  has  demonstrated  that  a  great  deal  of 
research  remains  to  be  done.  We  are  far  from  knowing  all  there  Is  to 
know  about  simulation,  both  in  concept  and  in  practice.  It  will  be 
a  long  time  before  we  come  to  a  point  where  we  wish  to  standardize  on 
a  single  language,  and  change  from  a  dynamic  era  of  research  and 
development  to  one  of  alow  evolution. 

The  greatest  challenge  today  liea  in  unifying  discrete-event  and 

continuous-time  simulation  languages.  Some  think  that  this  cannot  be 

done.  Some  think  it  should  not  be  done.  Certainly,  we  know  little 
★ 

about  how  to  do  it. 

The  researcher  faced  with  the  selection  of  a  research  project  in 
the  simulation  language  area  does  not  lack  alternatives.  There  are 
still  advances  to  be  mace  in  modeling  concepts;  our  ways  of  modeling 
both  static  and  dynamic  structures  are  incomplete.  And  certainly, 
the  fields  of  interactive  compilers  and/or  interpreters  and  graphics 
are  exciting  ones  and  in  the  mainstream  of  modern  programming  research. 

Today,  the  manager  or  programmer  faced  with  the  task  of  selecting 
an  SPL  does  not  always  have  a  clear  choice.  His  choice  will  probably 
be  less  clear  in  the  future,  as  languages  are  drawing  closer  together 
on  many  issues,  but  remaining  apart  on  others.  It  is  our  hope  that 
this  Memorandum  will  make  some  language  selection  choices  easier  and 
more  objective,  and  will  provide  some  direction  to  SPL  research. 


A  recent  publication,  D.  A.  Fahrland,  ''Combined  Discrete-Event/ 
Continuous  Systems  Simulacion,"  SRC-68-16,  Case  Western  Reserve 
University  Systems  Research  Center,  July  1968,  may  provide  the  needed 
Impetus  to  initiate  a  constructive  dialogue  on  this  topic. 


APPENDIX 

CHECKLIST  OF  FEATURES  FOR  SPL  EVALUATION 


Stoalcelon  profr«i»lr\§  l«nfuag««  Hwtt  b«  able  (u; 

{D  th«  €!•••••  of  objovti  witMn  • 

(2)  odjutt  tho  f>u«6or  of  tnt»*  objoett  ••  condition)  within  th«  tyiti*  vary. 

(3)  d«ttn«  charoctoriatlca  or  profoittaa  that  can  both  daactlba  and  dlffar- 
o-vttata  ohjacta  of  tha  aaaa  ctaaa,  and  daclart  nuaarlcal  codta  for  thaai, 

(4)  ralata  ob)a<ta  to  on#  anothar  and  to  thalr  coMon  anvlronaanc. 


Tha  haar^  of  ava<‘y  al«ulatlon  progra*.  and  avary  SPL  ii  a  efaa  connol  rrniran. 
Ita  (unctloaia  ara  alvaya  tha  aa«a:  to  advanca  alaulatinr  e  Ina  and  to  nalact  for 
axacutlon  a  progras  chat  parforaa  a  apaclflad  almilatlon  activity.  Ait  SPL  eual 
contain  auch  a  proftata.  atatOMMa  that  dafina  avanta,  acClvltlaa  or  procaaiaa, 
and  atataMAta  Chat  erganlaa  thaaa  avanta,  activltiaa  or  protaaiaa. 


fCdudorarUoa  nu*b«r  ganatatton 

MuUlpta  candoai  niabar  atraaaa 
AnCithatU  varlataa 

Sailing  fiM  a^lrtcal  tabla  look-up  dla  t  r  ibot  Iona 
Saa^Uni  froa  thaorac  leal  atactaiical  dlatribuc  lona 

ma  nicaac  thing  ona  can  nay  about  a  data  coPaition  apac  If  leal  Ion  la  chat  It  la 
unabtrualva.  ittlla  data  collaction  la  nacaaiary,  atattMinta  that  ara  wilttan  to 
obtain  data  but  ara  not  Chaaaalvaa  part  of  a  al^lacion  aodal'a  logic,  ahould  not 
obacura  tha  oparatlona  of  a  ■e4a)  In  any  way 


Varlaficaa  and  Standard  havlatlone 
fr«guan«y  Dlatrlbutlona 


IhMbar  of  obaarvat  Iona .  •axl«a  and  otnlna  for  all  varlablaa 
Sum.  and  awM  of  aguaraa  for  tlM*lndaptndanc  varlablaa 
tiM.walghtad  auM ,  and  auM  of  aqwataa  for  t  IM -dapandanr  varlablaa 
Varlabla  valwa  hiarograM  for  c  Ijm  >  tndapandant  varlablaa 
Tl«a*in-tcata  hlatctra*#  fnt  t ia»*dapan4aA|  varlablaa 
Tl«a  aarUt  plot#  ovar  apaclflad  tla*  IntarvaU 


Slnta  tha  production  of  raperta  la  tha  primary  taab  of  ail  pregrama,  whathar  thty 
era  run  Cor  program  chacbout ,  tot  tha  diapUy  of  compuCad  raaulta^  or  for  tha  prap* 
aration  of  alabetata  maeagatMAt  raporia  and  charti,  o  good  SPL  ahould  contain 
atactfliAtd  adaptad  to  all  dtaplay  aUoactona. 

<l>  Automatic  owtpwt  to  standard  format 
<2l  Pormat'Craa  output 
<))  Permattaa  output 
(4)  haport  ganaratora 


Kaportlng  axacwta-tlma  arrora  by  aourca  atattaani  ralatad  amaaagaa 

Olapiayl*^  lo^lata  program  flow  atatua  wt.ar  an  asa^wta'ilea  arccr  stcuri.  Thla 
•aana  diaplaytng  tha  antry  polnta  and  ralfvant  paramatari  for  all  function  and 
aubroutlna  calla  in  affact  at  tha  tima  of  tha  trror. 

Accaaalng  control  information  batwwan  avant  oaacuilura.  Thla  allowa  avtnt  tracing 
during  all  or  aaloctad  paria  of  a  program,  and  uaa  of  control  Information  In  pro- 
gr^  dlagnoattc  routinaa. 


Aa  Bimilatlon  la  aaaantlally  tha  mevamant  of  a  ayatem  modal  through  aimulated  t ima 
by  changing  lea  atata  daacrtptfona  ,  It  la  l^ortant  ihgt  an  SFL  provldt  a  convan* 
lant  machantam  Cor  apactCyvng  Initial  atatta.  Thla  can  ba  duna  aithar  by: 

(a)  a  apocial  loltlallaai Ion  form;  or 

(b)  eonvaniont  data  input  ttaramanta  and  formats. 

0m«  ah^ld  alao  b«  abla  to  aava  all  tha  Inlonaatlen  about  a  program,  including 
raltvaot  data  on  tha  atatua  of  aatarnal  atoraga  davicaa  and  paripharal  aqvlpmant 
and  rnatata  It  on  comnand. 


Program  rtadablllty 
ImacutlOA  afCUIamcy 
Modality  afCIclancy 
Doc\aaAtat  Ian 

fur  imatrwcclon 
for  inatallacton 
for  aMtetamaama 
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